[vtk-developers] Drawing performance problems with Cocoa; what is Render() exactly?

[Berk Geveci]

One solution would be to keep track of changes to the scene yourself.
Once you know the scene changed, call Modified() on the renderer and
schedule a render if necessary.

-berk

On 2/1/07, Mathieu Coursolle <mcoursolle at rogue-research.com> wrote:
> The application loads a data and creates a few actors, which represent
> different representations
> of the data (planes, surface, raycast, etc.). The VTK view is inside a
> window which also have check boxes
> to display or remove the actors from the renderer, as well as other
> controls to change some properties
> such as the color or lookup table.
>
> However, the MAC OS sends the drawRect message when the user clicks a
> check box, which makes the
> view to render.
>
> If backing store is off, and actors which are time consuming to render
> are displayed, the view is
> rendered before the check box gets selected, which cause a few seconds delay.
>
> By setting backing store on, this is not a problem, as nothing change in
> the window while the user
> clicks a check box. The render method then puts the backing image to screen.
>
> However, those check boxes are to add or remove actors from the scene,
> or to change properties. If
> backing store is on, some changes are not affected because the render
> method only checks for
> actor property change or mapper change. Adding/Removing actors or
> changing the lookup table are not
> checked in the render process, which makes the renderer to display the
> backing image again.
>
> Thank you.
>
> Mathieu
>
> ____________________________________________________________
> Mathieu Coursolle                   mcoursolle at rogue-research.com
> Rogue Research Inc.                 www.rogue-research.com
> Montréal, Québec, Canada
>
> >> I tried setting backing store on, which seems to solve the initial problem.
> >> The view is now only rendered when needed.
> >>
> >> However, the modified flag in the renderer is set if the actors have
> >> been modified.
> >>
> >> If an actor was created before the last Render() call, but added to (or
> >> removed from)
> >> the renderer after that last Render(), the check in the Render() method
> >> does not set
> >> the modified flag as the actor did not change. Is this the right
> >> behavior. Shouldn't
> >> it check if the prop collection changed also?
> >
> >In theory yes. But based on the same theory, it should also check if
> >anything upstream changed also. This pretty much takes you back to the
> >original problem of performance. I believe the current approach is to
> >leave it up to the application to check for modification of anything
> >but the renderer. What kind of performance change are you seeing
> >between the 2 cases? What is your use case?
> >
> >-berk
> >
> >>
> >> Thank you.
> >>
> >> Mathieu
> >>
> >> ____________________________________________________________
> >> Mathieu Coursolle                   mcoursolle at rogue-research.com
> >> Rogue Research                      www.rogue-research.com
> >> Montréal, Québec, Canada
> >>
> >>
> >>
> >>
> >> >Hi Sean,
> >> >
> >> >It does a few things, too many to remember :-) Look at the following
> >methods:
> >> >vtkRenderer::Render()
> >> >vtkOpenRenderer::DeviceRender()
> >> >
> >> >Beside all of the usual OpenGL render calls (which should be
> >> >relatively fast with display lists on), some information is sent up
> >> >the pipeline and is requested back. This should be very fast as long
> >> >as the number of actors in the renderer is relatively small (let's say
> >> >< 100).
> >> >
> >> >I believe there is a backing store option in the renderer. You might
> >> >want to investigate that. I am curious to know what you find, please
> >> >keep me posted.
> >> >
> >> >-berk
> >> >
> >> >On 2/1/07, Sean McBride <sean at rogue-research.com> wrote:
> >> >> Hi all,
> >> >>
> >> >> We have discovered a performance problem and are looking for some help/
> >> >advice.
> >> >>
> >> >> (First a short explanation of the Cocoa graphics model.  There are 2
> >> >> important classes: NSWindow and NSView.  A 'window' is not the same as
> >> >> in MS-Windows.  A 'window' refers to what an end user would call a
> >> >> window.  Views are not subclasses of windows.  An NSView lives in an
> >> >> NSWindow, and occupies a rectangular area.  An NSView does all its
> >> >> drawing from its drawRect: method.  drawRect: is never invoked directly,
> >> >> but rather the OS decides when a view needs to draw itself by sending it
> >> >> the drawRect: message, at which point a view _must_ draw itself.  If you
> >> >> want your view to redraw, you mark it dirty my calling [myView
> >> >> setNeedsDisplay:YES] and sometime later the OS will send the view a
> >> >> drawRect: message.  One has no control over when the OS will require
> >> >> one's view to draw, so drawRect: must be fast, and do the minimum needed
> >> >> to get the pixels onscreen.)
> >> >>
> >> >> In vtk there is an NSView subclass named vtkCocoaGLView.  Its drawRect:
> >> >> method invokes vtkRenderWindow's Render() method.
> >> >>
> >> >> So the questions are: what exactly does Render() do?  We know it draws
> >> >> (via OpenGL), but does it also do other computations?  Is Render()
> >> >> overkill when all we need is to draw?
> >> >>
> >> >> The problem is that the OS often sends vtkCocoaGLView a drawRect:
> >> >> message even though nothing (camera, scene, lights, etc.) has changed
> >> >> since the last drawRect: message.  Since we have no control over when
> >> >> the OS sends drawRect: we are looking to make it faster.
> >> >>
> >> >> Thanks!
> >> >>
> >> >> --
> >> >> ____________________________________________________________
> >> >> Sean McBride, B. Eng                 sean at rogue-research.com
> >> >> Rogue Research                        www.rogue-research.com
> >> >> Mac Software Developer              Montréal, Québec, Canada
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> vtk-developers mailing list
> >> >> vtk-developers at vtk.org
> >> >> http://www.vtk.org/mailman/listinfo/vtk-developers
> >> >>
> >> >
> >> >
> >> >--
> >> > Berk Geveci
> >> > Kitware Inc.
> >> > 28 Corporate Drive
> >> > Clifton Park, NY, 12065
> >> >_______________________________________________
> >> >vtk-developers mailing list
> >> >vtk-developers at vtk.org
> >> >http://www.vtk.org/mailman/listinfo/vtk-developers
> >> >
> >>
> >> --
> >>
> >>
> >>
> >
> >
> >--
> > Berk Geveci
> > Kitware Inc.
> > 28 Corporate Drive
> > Clifton Park, NY, 12065
> >
>
> --
> ____________________________________________________________
> Mathieu Coursolle                   mcoursolle at rogue-research.com
> Rogue Research Inc.                 www.rogue-research.com
> Montréal, Québec, Canada
>
>


-- 
 Berk Geveci
 Kitware Inc.
 28 Corporate Drive
 Clifton Park, NY, 12065