[vtk-developers] vtk performance - issue 1 - OpenGL state

Mark Beall mbeall2 at simmetrix.com
Wed May 16 20:43:37 EDT 2001


>> This first issue has to do with unnecessary calls to set
>> OpenGL state (please excuse me if this terminology is incorrect,
>> I'm not an OpenGL expert).
>> It seems that the best thing to do would be to have something keep
>> track of the state and only make the gl calls to change things
>> that need to be changed. The place that would seem to make the
>> most sense to do this would be within the renderer itself.
>> The proposed solution is to add the ability of the renderer to
>> keep track of this state and functions for the property
>> (and anything
>> else that changes these states) to call to set them. Then the
>> renderer will only change them if they need to be changed.
>
>The render window is the right place since it has a 1 to 1 mapping
>with the OpenGL context. I would suggest in OpenGLProperty doing a
>safe cast to an OpenGLRenderWindow and then calling all the opengl
>methods on the OpenGLRenderWindow which will keep track of state in
>its ivars and only make the OpenGL call if required. To make this fly
>the OpenGLRenderWindow classes must be reorganized.  I would suggest
>
>vtkRenderWindow  ---> vtkOpenGLRenderWindow -->
>
>(vtkWin32OpenGLRenderWindow and vtkXOpenGLRenderWindow)
>
>Where the platform independent code is in vtkOpenGLRenderWindow and
>the Win32 and X code is in the respective subclasses. Also some of the
>OpenGL calls in Property can probably be eliminated with a few if else
>statements.

Ken,
It seems from what I've found that it's possible that there could
be multiple threads rendering into the same OpenGL context. Now,
vtk isn't doing this now, but it would seem that it could be wanted
in the future. Given this it would seem that it might be better to
keep the state in the renderer. Also I think this might make it 
easier to do some other optimizations. What do you think?

mark
 




More information about the vtk-developers mailing list