Updates to GLX_EXT_texture_from_pixmap

[Kristian Høgsberg]

Deron Johnson wrote:
> 
> James Jones wrote On 03/30/06 12:30,:
>> I still would
>> like to make this [drawable locking] part of a separate extension though.  As I've 
>> mentioned before, people may need it in cases where 
>> texture_from_pixmap isn't applicable.  It also seems like something 
>> better implemented mostly in core X, with some support from 
>> drivers, rather than entirely in drivers as part of 
>> texture_from_pixmap.
> 
> I am concerned that LockDrawables will introduce unnecessary overhead in
> the tfp bind process. Since the composite manager should not access the
> contents of the drawable until it is known to be locked, and
> LockDrawables is an X request, it is necessary that LockDrawables be a
> synchronous request, that is to say, it requires a round trip to the
> server. My understanding of tfp bind, on the other hand, is that it is a
> direct-access opengl routine which bypasses the X protocol and requires
> less overhead.
> 
> Having a separate LockDrawables extension for other uses is okay, but I
> don't think we should rely on it for tfp bind. I recommend that tfp
> bind/unbind include their own locking semantics with no need to make
> separate locking calls.

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.

Kristian