Re: Scrolling text that doesn't flicker
- From: "Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx>
- Date: Sun, 12 Nov 2006 21:28:28 -0800
"Dave Sexton" <dave@jwa[remove.this]online.com> wrote in message
news:%23DcSGGuBHHA.2316@xxxxxxxxxxxxxxxxxxxxxxx
But for scrolling text you can't draw everything only once. It's
scrolling!
Yes, you can (assuming you can draw the background with the text as you
described). There will be x frames per second, for each frame if you draw
each pixel on the surface only once then you don't need double buffering.
I really don't understand what you mean. How would that prevent Windows
from clearing the render target before the next operation?
He's saying that, if you had a way to ensure that each pixel on the screen
that has changed is drawn only once, setting it to the exact desired new
value, you can, once per frame, draw everything only once.
Obviously something animated has to be drawn multiple times. But the
flicker doesn't result from that. It results from drawing things multiple
times *per frame*. That's what he means to avoid.
In theory, it's even possible to do so (see my other post, about using
regions to mask the text area while filling the remaining background). In
reality, that's a) a much more complicated solution than using an off-screen
buffer, and b) may not even perform as well (since it would rely on using
regions to mask the text area while the background is being drawn).
I always thought double-buffering worked like the swap chain in DirectX,
where the back buffer is simply presented instead of the target being
cleared. Without the buffer, I assumed Windows will clear the target
automatically for each WM_PAINT message, causing a flicker.
Care to explain in more detail?
This is why I dislike the use of the term "double buffering" to describe
this. It's similar to, but not exactly the same as, the existing
double-buffering (or even triple-buffering, as is sometimes the case) used
in DirectDraw. In DirectDraw, double-buffering means there are two entire
frame buffers. One is always being used by the video card's RAMDAC to
display an image on the monitor, and the other is the one being drawn to at
that given moment. Once drawing has been completed, the entire active frame
buffer is switched (flipped), and the process starts anew.
This is kind of what the .NET "double buffering" is doing, except that it's
not a low-level hardware thing. There's an alternate, off-screen buffer and
rather than flipping the actively displayed buffer, the off-screen buffer is
simply copied to the active on-screen buffer. I don't like using the same
term for both, because it confuses the issue.
By doing this, any pixel that changes on the screen is drawn exactly once
for a given change (frame). Which is what needs to happen to avoid flicker.
And it certainly can happen that way, even as the text is scrolling. The
requirement is that the drawing happens once for each change, not that it
only happen once period.
Pete
.
- Follow-Ups:
- Re: Scrolling text that doesn't flicker
- From: Dave Sexton
- Re: Scrolling text that doesn't flicker
- References:
- Scrolling text that doesn't flicker
- From: pigeonrandle
- Re: Scrolling text that doesn't flicker
- From: Dave Sexton
- Re: Scrolling text that doesn't flicker
- From: Michael C
- Re: Scrolling text that doesn't flicker
- From: Dave Sexton
- Re: Scrolling text that doesn't flicker
- From: Michael C
- Re: Scrolling text that doesn't flicker
- From: Dave Sexton
- Scrolling text that doesn't flicker
- Prev by Date: Re: Scrolling text that doesn't flicker
- Next by Date: Higher CPU Utilization on Windows form resize
- Previous by thread: Re: Scrolling text that doesn't flicker
- Next by thread: Re: Scrolling text that doesn't flicker
- Index(es):
Relevant Pages
|