<br><br><div class="gmail_quote">On Sat, Mar 7, 2009 at 11:21 PM, David Taht <span dir="ltr"><<a href="mailto:d@teklibre.com">d@teklibre.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>I am going to disagree with this slightly. If you are doing different<br>
kinds of updates to the screen it helps to be sending the draw commands<br>
as fast as possible, so that the display hardware has smaller chunks to<br>
render at a time.</blockquote><div><br>video hardware works like audio hardware. it redraws at a fixed frequency, by painting an offscreen framebuffer to the real framebuffer. your description makes no sense to me. rendering is done on a schedule determined by the hardware (just as with audio), its not based on what software is (or is not) doing. between two video vertical retraces, the h/w is busy rendering into the offscreen buffer; when the retrace starts, the video drawing h/w starts rendering what was the offscreen buffer to the pixels, and the rendering h/w switches to use what used to be the "real" framebuffer. the buffer switching is not necessarily literally like this (video RAM is special), but conceptually, this is what is happening. you can feed stuff in bits and pieces to the renderer, or in big chunks - either way its not going to display stuff till the next vertical retrace begins. <br>
 </div></div><br>