Re: Re: how to write snappy benchmark?

Mark Vojkovich <[email protected]>
Newsgroups gmane.comp.xfree86.forum
Message-ID <[email protected]>
On Sun, 6 Jul 2003, Allen Akin wrote:

> On Sun, Jul 06, 2003 at 01:27:38PM -0400, Havoc Pennington wrote:
> | ...
> | If you set the background pixmap to exactly the current contents of a
> | window, you could avoid flashing, which is what we were discussing a
> | bit. However, there is a memory cost (you have a large pixmap the size
> | of every window).
> 
> There's at least one similar approach worth considering --
> double-buffering using a single back buffer for the entire screen, with
> synchronized buffer-swap during vertical retrace.  This avoids flashing*
> and places a low upper bound on the amount of extra memory required.
> 
> I've used systems liked this.  They're quite effective, especially given
> the drawing rates of modern desktop hardware.
> 
> Allen
> 
> * Assuming the apps are capable of redrawing quickly enough to maintain
> interactivity, and the scheduler gives them time to do so. 

   I think if that were true we wouldn't be having this discussion.
This won't decrease the latency, so if you can currently watch the
apps redraw, this merely makes it so you can't watch them redraw
but you have to wait just as long.

   Most OpenGL apps are the types of apps that don't need to handle
expose events.  And it's a good thing too, because they'd probably
suck at it.

			Mark.

> It's a good
> assumption for most apps and the past few generations of hardware.  For
> fallback, a swap timeout on the order of two frame times is necessary,
> and apps that miss the timeout may flash.
> 
> GLX extensions for swap control already exist and might be useful in the
> 2D world if toolkit developers wanted to give this sort of thing a try.
> _______________________________________________
> Forum mailing list
> [email protected]
> http://XFree86.Org/mailman/listinfo/forum
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.