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

[Lisa Sobierajski Avila]

Hello Mark,

I don't think you can keep the state in the renderer - there is one context 
for the render window which is shared by all renderers in that render 
window. The state of the context can be changed by more than one renderer - 
therefore a renderer cannot know the state (unless you broadcast all state 
changes to all renderers).

Multiple threads rendering to the same context is a scary thought. I don't 
think most implementations of OpenGL are thread-safe. And the relevant 
parts of VTK are not thread-safe either. Even if these issues were handled 
- what does this do to the state of the context? Is state a per-thread 
thing or does it need to be communicated between threads?


Lisa


At 08:43 PM 5/16/2001, Mark Beall wrote:
> >> 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
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers