[vtk-developers] vtkOpenGLPolyDataMapper::RenderPiece

[Lisa S. Avila]

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