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

[Berk Geveci]

> 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