DRI2 Design Wiki Page
keithp at keithp.com
Thu Oct 4 09:34:13 PDT 2007
On Thu, 2007-10-04 at 01:27 -0400, Kristian Høgsberg wrote:
> There is an issue with the design, though, related to how and when the
> DRI driver discovers that the front buffer has changed (typically
Why would the rendering application even need to know the size of the
front buffer? The swap should effectively be under the control of the
front buffer owner, not the rendering application.
As far as figuring out how big to make the rendering buffers, that's
outside the scope of DRM in my book. The GLX interface can watch for
ConfigureNotify events on the associated window and resize the back
buffers as appropriate.
With Composite, we never resize pixmaps, we leave the old ones around
and create new ones in the new size. When the last use of the old object
is finished, the old pixmap is cleaned up. This means that applications
don't have to synchronize their use of the pixmap to potential window
Moving cliprects and buffer tracking into the kernel eliminates
the need for an SAREA. The clip rects are only needed on swap
buffers; this is done by the kernel, which always has the latest
You'll still need to lock the swap out while the X server is busy
recomputing the clip lists and repainting the rest of the screen. Which
means we'll need some kind of lock on the front buffer that the vsync
thread grabs before looking at the clip lists.
keith.packard at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part
More information about the xorg