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

[Mathieu Coursolle]

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