[vtkusers] Re: Rendering slowed down after recent CVS update

[Paul Melis]

Paul Melis wrote:

>Sean McBride wrote:
>
>>/On 1/16/08 4:24 PM, Paul Melis said:
>/>/
>/>>/And another reply to myself...
>/>>/After going back to a CVS version of VTK of October 1st the problem 
>/>>/seems to be gone. So something changed in VTK between october and today 
>/>>/that influences the render performance, probably due to a software 
>/>>/fallback suddenly being used in the NVidia driver.
>/>>/    
>/>>/
>/>/
>/>/Next try Nov 1, Dec 1, etc. until you have it narrowed down to between 2
>/>/days... tedious, but easy.  You'll probably find the problem this way.
>/>/  
>/>/
>/Well, I made a little script that did all the hard work of checking out 
>a CVS version for specific date, configuring it with cmake, building it, 
>setting appropriate environment variables and then running a little test 
>application. The results indicate that the problems start with commits 
>done on October 27. I suspect the changes relating to alpha handing (for 
>bug 2347) in vtkOpenGLRenderWindow.cxx and friends, although I don't see 
>anything suspicious in the code. Most of the changes seem related to 
>depth peeling and using different blending, but I'm not enabling depth 
>peeling and are also not using any transparent geometry.
>
>  
>

Okay, further testing shows it is indeed related to using a different 
blending function. If I take the faulty revision and only comment out 
the calls to glBlendFuncSeparate in vtkOpenGLRenderer.cxx and 
vtkOpenGLRenderWindow.cxx the problem goes away, i.e. performance is 
restored. So it looks like a software fallback is used as side-effect of 
this call. Yuck. The card (actually driver) says it's OpenGL 1.5 
capable, and glBlendFuncSeparate was introduced in 1.4. But it doesn't 
seem to be hw-accelerated...

I guess there's not much of a work-around for this, except a card 
upgrade :-/

Paul