On Wed, 2007-11-28 at 06:19 +0100, Soeren Sandmann wrote: > - When a client wishes to copy something to the frontbuffer (for > whatever reason - glXSwapBuffers(), glCopyPixels(), etc), it uses > plain old XCopyArea() with the generated pixmap. The X server is > then responsible for any clipping necessary.
Using a plain old XCopyArea will make scheduling this in the kernel quite a bit harder; if the kernel knows it's doing a swap buffer, then it can interrupt ongoing rendering and do the copy at higher priority, precisely when the vblank interrupt lands. Plus, you've just added the latency of a pair of context switches to the frame update interval. Also, placing any user-mode code in the middle of the interrupt->blt logic will occasionally cause tearing on the screen; having the kernel push the blt just-in-time means we'd have reliable swaps (well, down to the context switch time in the graphics hardware). I like the simplicity, and we'll certainly be wanting the pixmap-from-object API for lots of other fun stuff, but buffer swaps may still need more magic than we can manage at this point. I also wonder what the effects of a compositing manager are in this environment -- ideally, your 'buffer swap' would be just a renaming of two buffers, and not involve any data copying at all. Keeping all of that hidden behind an abstract API will let us move from copying the data to swizzling pointers without breaking existing apps. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
