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.
--
[EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
-- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
