Updates to GLX_EXT_texture_from_pixmap

[Jamey Sharp]

On Fri, Apr 07, 2006 at 10:31:40AM -0700, Deron Johnson wrote:
> Jamey Sharp wrote On 04/03/06 16:24,:
> > If the compositing manager uses pure X protocol (no direct rendering)
> > then the X server can just stop processing the compositor's request
> > stream until the lock is acquired. That's different from forcing the
> > client to wait for a round-trip, which is what is usually meant by
> > "synchronous requests" in X. For XCB we've taken to calling these
> > "non-void requests" instead, since XCB makes all requests somewhat
> > asynchronous from the client's point of view.
> 
> Regardless of how you implement it, the key behavior is that the
> call to LockDrawables must not return until the lock has been acquired.

If you mean the "XLockDrawable" function on the client must not return
until the lock has been acquired in the server, then I don't agree. Not
all drawable locking clients need to wait for the server. Direct
rendering clients need to wait, but you can achieve that with an XSync
after XLockDrawable.

Consider XCreatePixmap. As soon as it returns, the application can call
XDrawSegments and cairo_fill and all sorts of drawing operations, even
though the server may not have even received the CreatePixmap request
yet, let alone allocated memory for the pixmap. The server promises not
to process the drawing operations until the CreatePixmap request has
completed, and that's good enough.

The proposed LockDrawable request can operate the same way. And it
should, because synchronization between the client and server is
expensive.

Hope that helps; I'm not going to try to argue it any more.

--Jamey
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20060408/b8cecd89/attachment.pgp>