compiz on aiglx

[Kristian Høgsberg]

James Jones wrote:
> On Thursday 09 March 2006 12:23, Kristian Høgsberg wrote:
>>   You could do something like:
>>
>>    static const int attribs[] = {
>>      GLX_DRAWABLE_TYPE,         GLX_WINDOW_BIT,
>>      GLX_RENDER_TYPE,           GLX_RGBA_BIT,
>>      ...
>>      GLX_DOUBLEBUFFER,          GL_TRUE,
>>      GLX_INCLUDE_INFERIORS_EXT, GL_TRUE,
>>      None
>>    };
>>
>>    fbconfig = glXChooseFBConfig(dpy, scrnum, attribs, &num_configs);
>>    ctx = glXCreateNewContext(dpy, fbconfig[0], renderType, NULL, False);
>>
>> to get a double buffered, include inferior gl context for the root
>> window, without worrying about which visual the root window has been
>> assigned.
> 
> This sounds reasonable.  Could you write up a quick extension spec for this?  
> I would rather not have all 3 methods.  If people really are interested in 
> using the include inferiors method after an overlay window approach is 
> available, it seems best to have it defined as an FBConfig as you suggest.  
> We chose an X option only because it was thought this would be a temporary 
> solution during the transition period.

I'll give that a shot.

>> It sounds like Keith and Deron prefer the magic overlay window approach,
>> but I think this approach is simpler and a lot cleaner and it almost
>> already works, we just need the GLX_EXT_include_inferiors extension.
>> That should be pretty easy, though, as it just defines the
>> GLX_INCLUDE_INFERIORS_EXT token.
> 
> A major benefit of the overlay window is the ability to create the window 
> being drawn into with whatever FBConfig you like, rather than relying on the 
> root window's visual to contain all required functionality.  This may seem 
> like a minor point, but it could be a major if you preferred to render the 
> desktop using a stereo visual, or if the default visual did not provide 
> stencil bits, etc.  As you say, I think there is room for both approaches, I 
> just would hate to see the quick availability of an FBConfig extension kill 
> off all interest in the composite overlay window.

So I guess this is one point where I'm not sure how glXCreateNewContext 
should work.  My impression was that you can pass in any FBConfig you 
want when you create the context and when you later call glXMakeCurrent 
that FBConfig will override whatever GL attributes are associated with 
the root window visual.  In other words, the FBconfig attributes are 
independent of and override the attributes of the default visual.  So 
even if your root window visual doesn't have doublebuffering, you can 
override that by using an FBconfig that does.

[...]

> I think it is the most desireable behavior, but I disagree that it is the most 
> reasonable.  All sides of the equation (the oblivious applications, the X 
> server, the X and OpenGL drivers, the composite manager, and ideally a 
> bullet-proof specification) must be taken into account when creating a 
> reasonable solution.

I guess, after all, I'm happy with the undefined behaviour.  I can see 
how it will be difficult to word a usable description of what will 
happen in the receiving-rendering-while-bound situation.  Leaving it 
undefined leaves enough room for the tfp implementation to avoid 
blocking or copy-on-write, and the compositing manager can block updates 
to the pixmap either by grabbing the server or by using a higher level 
protocol, such as the pixmap-ownership idea I sketched above.

thanks,
Kristian