Re: Re: Visual problems and GLX (again)

OK, I think I've finally gotten to the bottom of all this.

I think we've just been getting lucky up until now, in terms of which 
GLX visuals are used for the various windows.

For example, in the crut_fan.conf demo:
1. The Readback SPUs do their depth compositing by using the
    stencil buffer.  So, the Render SPU that we composite into
    has a window and rendering context made from a GLX visual
    that has stencil planes.

2. Since we're using 'render_to_crut_window' the render SPU
    draws into the GLUT window instead of the stencil-capable
    window mentioned above.  HOWEVER, the GLUT window wasn't
    made with a stencil-capable visual!

Sometimes visuals have extra attributes (like stencil) that we didn't 
request.  That's when we got lucky.  Otherwise, we'd likely get 
BadDrawable errors.

Next, I found a bug in the psubmit_crut.c program: it never called
MakeCurrent()!  I don't know how that ever worked.

I've also updated the demo to explicitly create a new window, rather 
than rely on the default window.  This involved adding a new 
crutCreateWindow() function.

I'm gradually removing all remnants of the "default window" code from 
Chromium.  In the early Chromium days, there were no functions for 
creating windows, contexts and binding them, so a default rendering 
context and window were made up front and used everywhere.  That's 
been supported through today for compatiblity reasons.  But it 
sometimes causes problems.

The patch I posted before was a hack.  The Readback SPU, since it's 
derived from the Render SPU, should query 'default_visual'.  The 
Binary swap SPU too.

I'll check in my changes in a bit.

-Brian



Mike Houston wrote:
> That works.  Removing the assertion doesn't quite do what we want since 
> the render SPU still creates a bogus default window with the wrong 
> visuals.  For some reason, we have a situation in which we try to set 
> thing up before we have a window.
> 
> -Mike
> 
> Brian Paul wrote:
> 
>> Mike Houston wrote:
>>
>>> We seem to be back with issues getting correct visuals for certain 
>>> apps like Raptor.  I'm hitting an assertion failure because the 
>>> context->visBits are not matching window->visBits (assert fail on 
>>> line 797 of readbackspu.c).  This only seems to occur when running 
>>> CRUT based applications who do their window creation through CRUT.  
>>> crut_ring.conf and crut_fan.conf are simpiler cases that exhibit this 
>>> behavior.
>>>
>>> The context visbits are sane, but the window's visbits are zero (!).  
>>> It seems that CRUT got broken along the way.  My guess is that window 
>>> creation is failing oddly, but it's going to be awhile to track this 
>>> down.  I'm currently running on ATI hardware, but I'd wager things 
>>> are borked on Nvidia and 3DLabs as well.
>>>
>>> -Mike
>>
>>
>>
>> Mike, try this patch.
>>
>> diff -r1.21 readbackspu_init.c
>> 68a69
>> >       window->visBits = CR_RGB_BIT | CR_DEPTH_BIT | CR_DOUBLE_BIT;
>>
>> Or, I think you can simply disable the assertion for the time being.
>>
>> I think I know what the real problem is.  I'll work on a proper fix.
>>
>> -Brian
> 
> 
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Chromium-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt