Re: double buffering
- From: Just d' FAQs <nobody-here@xxxxxxx>
- Date: Sun, 26 Jun 2005 06:52:48 -0500
On Sat, 25 Jun 2005 22:28:15 -0700, "vsgdp" <spam@xxxxxxxxxx> wrote:
>I have read two reasons for double buffering:
>
>1. To prevent updating the memory the monitor is drawing from while it is in
>the middle of drawing a frame.
>
>2. To prevent flicker from overdraw.
>
>Most information I have found gives one reason but not the other. Which is
>it and has one become outdated?
If you're learning about double buffering, you might also want to look
at triple buffering.
<http://www.intel.com/support/graphics/sb/CS-004527.htm>
Both reasons for double buffering can be meaningful, but the first has
two aspects. Once upon a time, not so long ago, we did not have frame
buffers because memory was expensive and slow. The rate at which video
signals sucked out even 1-bit pixels exceeded what RAM could provide.
One clever solution was a special RAM design that clocked out the bits
sequentially, rather than going through the usual random addressing
logic. Even so, writing while reading was proceeding did not work too
well. Today, RAM is much cheaper and faster, and read-write conflicts
are less of an issue for access time.
However, a logical problem remains. If we draw into an image as it is
being sequentially displayed, we can easily display part of the old
image along with part of the new image. The visual effect can be ugly.
We prefer to preserve the integrity of each frame, to draw it as a
whole and to display that whole. Multiple buffers help us do that.
The story does not end there, because we lose something as well. To
accelerate the flow of graphics through the rendering to the screen,
we not only use multiple buffers, we also heavily use pipelining. The
idea is, again, that while one part of the system is doing one thing
another part can be doing something different. This does give us high
speed, but it also introduces latency. The problem can be especially
severe with a head-mounted display. Our vestibulo-ocular system has
evolved to give tight coordination between our head movements and our
visual perception. A HMD is not so evolved. The head moves, a sensor
detects and measures, data is sent to the CPU, the graphics program
responds, a new frame is rendered, and finally the eyes see the new
display. This is an enormous amount of latency, far more than a human
brain will gracefully accept.
As a vivid analogy, imagine that while driving a heavy truck you see
the car ahead of you slam on its brakes. From visual cue to dead stop
is a very long time, more so at higher speeds. Just hope you're the
truck and not the car, because we have not only the finite reaction
time of the driver, but also the limited rate at which the brakes can
dissipate the momentum of a fast-moving massive vehicle. Thus latency.
.
- Follow-Ups:
- OT: HMD (was: double buffering)
- From: Przemyslaw Koprowski
- OT: HMD (was: double buffering)
- References:
- double buffering
- From: vsgdp
- double buffering
- Prev by Date: Re: double buffering
- Next by Date: Spline/Curve/Points to Arcs
- Previous by thread: Re: double buffering
- Next by thread: OT: HMD (was: double buffering)
- Index(es):
Relevant Pages
|
