Updates to GLX_EXT_texture_from_pixmap

[Deron Johnson]

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. These provide
safe, coherent semantics for all clients of tfp. We need such a
mechanism and it is entirely reasonable for all tfp implementations to
support these semantics. Furthermore, it is my contention that
tfp bind can lock the drawable without generating X protocol.
It is also possible for the OpenGL implementation to block out both
direct rendering OpenGL clients and X clients during the time the lock
is held. I advocate that we stick with the previously agreed upon
semantics until we can come up with a case where these semantics are
not implementable.