[vtk-developers] vtkOpenGLPolyDataMapper::RenderPiece

Tue May 29 19:21:17 EDT 2001

Lisa,
We are working on ways to prevent updates being done when they
aren't needed, but in a different way than you suggest, I'd
like your (and others) comments. 
The context of this decision is that we know what things will
be changing and what things won't, so we want to be able to
tell vtk this. What we decided to try is to put a flag in 
vtkActor (although I think it may have already been pushed up 
to vtkProp3d, perhaps should go higher in the hierarchy), that 
controls this. This can have 3 values: update always, update once, 
and don't update. If it's "update always" then things work the way 
they do now. If it's "update once" then everything is updated and 
then the state is set to "don't update". If it's "don't update" then
only things needed for rendering happen. 
The nice thing about this is that the rendering loop isn't changed
and there can be some actors that update all the time and some
that don't. 

Along with this we are trying to also make things faster in
the case where there are updates that need to be checked. I think
at this point we've increased the performance of our test case (with
1000 actors) by a factor of 4 or so, however it's still about a
factor of 3 off of having the same speed as having just one actor
with the same geometry to display. One thing that I would like
to see is a test case added to the regression tests that checks
the performance with a large number of actors. Otherwise we risk
having all this work be for nothing.

mark 

On 5/29/01 2:17 PM Lisa S. Avila (lisa.avila at kitware.com) wrote:

>Hi Jim,
>
>The only problem there is that on some systems a mutex lock / unlock is 
>fairly slow - so 120,000 would be awful.
>
>Another option we once discussed was to have a "don't update" version of 
>rendering. That is, a version of Render() that doesn't update any props, 
>doesn't call any start / end methods, etc. This way you know that you are 
>still the current context. Of course that means restructuring all the code 
>that currently calls MakeCurrent().
>
>Lisa
>
>
>
>At 01:48 PM 5/29/2001, Miller, James V (CRD) wrote:
>>I believe all the MakeCurrent calls query to see if the current context 
>>matches the render window.
>>If it matches, then glMakeCurrent is not called. We are assuming here that 
>>determining which context
>>is current is lightweight in comparison to actually switching the context. 
> >From your test results,
>>however, it looks as though just querying which context is current takes 
>>50% longer than all the call
>>lists (?), i.e. asking what the current context is is a pretty heavyweight 
>>call.
>>
>>Sounds like the only solution is to keep a global on what context is 
>>current and mutex around it (in
>>case multiple threads are active). I wonder if VTK should have a "thread" 
>>object that gets pushed
>>through the rendering system.  Then the rendering system could query the 
>>thread object as to what the
>>current context for the that thread is.
>>
>>
>>
>>-----Original Message-----
>>From: Mark Beall [mailto:mbeall2 at simmetrix.com]
>>Sent: Tuesday, May 29, 2001 11:42 AM
>>To: vtkdev
>>Subject: Re: [vtk-developers] vtkOpenGLPolyDataMapper::RenderPiece
>>
>>
>>Hi Lisa,
>>This is important with respect to our little quest to get good
>>rendering speed with a large number of actors. In our test all
>>these calls to MakeCurrent take 50% longer than all the calls
>>to glCallList, so we would like to eliminate them.
>>
>>mark
>>
>>On 5/29/01 9:50 AM Lisa S. Avila (lisa.avila at kitware.com) wrote:
>>
>> >Hi Bob,
>> >
>> >MakeCurrent must be called any time the window may have become uncurrent
>> >(for want of a better term!) This can happen unexpectedly - and I actually
>> >spent many hours on several problems tracking it down to an uncurrent 
>> window.
>> >
>> >During the rendering process a prop may update, causing its mapper to
>> >update. The mapper may get data that is pulled from another window -
>> >causing that other window to become current. Or, a start / end method on
>> >some filter may have a render call into another window (as is done with the
>> >pipeline viewer)
>> >
>> >If you think this is a serious issue, we can start keeping "global" state
>> >information in the render window. You'll still make the 120,000 calls, but
>> >they will simply check the current state and return if no MakeCurrent is
>> >actually necessary.
>> >
>> >Lisa
>> >
>> >
>> >At 02:55 PM 5/25/2001, obara wrote:
>> >>Hi Folks,
>> >>
>> >>Doesn't vtkOpenGlRenderWindow::MakeCurrent() only have to be called once
>> >>when rendering the window?  We were rendering a simple scene 120x's and
>> >>found this function being called 120,000 because
>> >>vtkOpenGLPolyDataMapper::RenderPiece() calls
>> >>vtkOpenGlRenderWindow::MakeCurrent().
>> >>
>> >>At least I didn't ask anything about indentation or where to put braces.
>> >>
>> >>Thanks in advance,
>> >>
>> >>Bob
>> >>
>> >>Robert M. O'Bara
>> >>Senior Software Engineer
>> >>Simmetrix Inc.
>> >>1223 Peoples Ave.
>> >>Troy, NY 12180
>> >>
>> >>Lab: (518) 276-2867
>> >>Main Office: (518) 276-2729
>> >>
>> >>
>> >>
>> >>_______________________________________________
>> >>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
>>
>>_______________________________________________
>>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
>
>
>_______________________________________________
>vtk-developers mailing list
>vtk-developers at public.kitware.com
>http://public.kitware.com/mailman/listinfo/vtk-developers