DRI2 Design Wiki Page

[Keith Packard]

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
> resizing).

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
size changes.

        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
        clip rects.
        
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...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20071004/b69d4c08/attachment.pgp>