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

[Mark Beall]

Hi Lisa,
Since the renderers are called one after the other, we were just
planning on having each of them set the state to a known state
at the start of the rendering process (or they just undo any
state changes at the end and everything is in a known state for
the next renderer). At this point we've implemented in the renderer (it
was actually done before I sent the first email), to move it to
the render window later wouldn't be a big deal.

Sun's OpenGL implementation is (or has a mode where it is) thread
safe. I don't know what, if any, restrictions there are on that.

mark 

On 5/16/01 11:07 PM Lisa Sobierajski Avila (lisa.avila at kitware.com) wrote:

>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
>
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers