On Tue, 2008-09-09 at 19:34 +0200, Michel Dänzer wrote: > On Tue, 2008-09-09 at 10:11 -0700, Keith Packard wrote: > > On Tue, 2008-09-09 at 18:41 +0200, Michel Dänzer wrote: > > > > > GLX_EXT_texture_from_pixmap needs the real front buffer. > > > > Sure, but that's not through DRI2, this just references the object as an > > X pixmap. > > I don't understand what you mean. How would a direct rendering, > zero-copy implementation of GLX_EXT_texture_from_pixmap work without > getting the pixmap buffer ID via DRI2GetBuffers?
I assumed that GLX would do this part of the protocol, not DRI2; probably just a misunderstanding of how this all works at a protocol level though. > So in order to find out the effective sequence number, the client would > need to keep incrementing the target number and check for the error? > Doesn't sound very appealing to me. Yeah, the protocol doesn't exactly provide any way of knowing what the current vblank sequence number is. > Not to mention X protocol errors tend to be a PITA. In what way? > That mechanism could be basically the same as the existing > sync-to-vblank mechanisms, but with 'vertical blank' replaced by > 'compositing manager screen update'. So it would provide the client with > a way to express the display frame at which the buffer swap should take > effect and to synchronize to the compositing manager making it so. We chatted about this and Kristian suggested that we would throttle the app to vblank rate, rather than compositing manager rate. On second thought, perhaps driving this from the compositing manager would make sense. Somehow we'd have to connect compositing manager operations to specific client actions though; I'm not sure we've got protocol to do that at this point. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xorg
