Updates to GLX_EXT_texture_from_pixmap

[Jamey Sharp]

On Mon, Apr 03, 2006 at 03:24:03PM -0700, Deron Johnson wrote:
> James Jones wrote On 03/31/06 15:05,:
> > LockDrawables would not always be a synchronous request.  It only 
> > needs to be synchronous if the composite manager is using direct 
> > rendering.  Note that the example I suggested accounted for this.  
> > Alternatively, LockDrawables could take a boolean argument making 
> > it optionally synchronous.
> 
> How can a lock operation not be a synchronous request? By the very
> definition of a lock the process trying to acquire a lock must block
> until the lock is granted. If the LockDrawables request is not
> always synchronous, the client could end up accessing the drawable
> when it is not actually locked.

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.

For direct rendering compositors, this same approach, of freezing
processing of the compositor's request stream, should work as well.
However a round-trip is necessary in that case, so such a client needs
to call XSync or make some other round-trip request after the
LockDrawable request, as James Jones originally described.

--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/20060403/a6c51863/attachment.pgp>