Updates to GLX_EXT_texture_from_pixmap

[Adam Jackson]

On Monday 03 April 2006 18:30, Deron Johnson wrote:
> Kristian Høgsberg wrote On 03/31/06 12:43,:
> > So wouldn't it make sense to keep the locking out of tfp and leave it to
> > the compositing manager as originally suggested?  What your describe
> > above is basically the rationale for keeping the behaviour undefined -
> > it relies on a mechanism outside tfp to stop applications from rendering
> > to the pixmap.  We can investigate different mechanisms, from brute
> > force server grabs to protocols for fine grained client/compmgr
> > interaction, but through all of that we can use the same tfp extension.
>
> I'm not sure we are on the same page in this discussion. What I am
> proposing is that we stick to the original semantics that the whole
> group of us agreed on at the X conference, namely, that tfb bind lock
> the drawable and that tfp unbind unlock the drawable.

From my notes: (http://people.freedesktop.org/~ajax/xdc2006-notes.txt)

"The spec as currently written doesn't define whether it acts like an alias to 
the pixmap storage (a la APPLE_client_storage) or whether it acts like a copy 
like glTexImage2D.  The consensus seems to be that it has to act like a copy.  
This doesn't preclude optimizations where the copy is deferred, copy-on-write 
style, or even elided if the pixmap isn't modified between Binds, but that's 
an implementation detail.  However to ensure that the bound texture image is 
stable, you still need to grab the server; doing any better will require some 
sort of protocol between producer and consumer."

This is very much not the same thing as acting like a lock.

ObBug: 2142.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20060403/b34e679b/attachment.pgp>