Around 18 o'clock on Mar 9, Michel Daenzer wrote:
BTW, the composite extension will require buffer swaps to be handled by the X server (as well as per-context buffers, ...), so we might as well start planning how to get there. :)
Ah, Composite isn't as X-centric as it might first appear...
Composite just places X windows in off-screen buffers, it doesn't require that their contents be rendered with X primitives. I sure hope to build a Composite manager which uses GL instead of X for this operation, in which case the buffer swapping will be under GL control.
2D APIs provide a way of painting surfaces with content; what shape those surfaces take shouldn't be limited to flat areas of the screen at constant Z.
I'm a little unclear on how this works. Excluding the pageflip case, in the "current" setup we have an offscreen backbuffer that needs to be copied to the frontbuffer. This happens completely under the control of the 3D driver. With composite, are both the backbuffer and the frontbuffer offscreen? In that case the 3D driver would just do a pointer swap and tell the window manager / X-server (or whatever) to recomposite, right?
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
