[vtkusers] vtkScalarBarActor & Disappearing actors.

[Charl P. Botha]

On Tue, 2003-03-11 at 11:14, Ron Inbar wrote:
> I noticed my application's performance was very poor, for no apparent
> reason; the CPU was at full capacity when it should have been well below
> that.
> 
> I used a software profiler to locate the bottleneck, and it showed that
> vtkOpenGLPolyDataMapper::Draw was getting called repeatedly, when I expected
> it to be called only after something changed.
> I used the debugger and found out that the last part of the test is often
> satisfied:
> 
> ren->GetRenderWindow() != this->LastWindow

This is most probably because you were sharing vtkActors/vtkTextures
between RenderWindows.  With the current architecture of VTK, this is
not recommended.

> I commented it out to see what happens and then that strange behavior
> started to occur.  Eventually I figured out that it had to do with
> context-switching and display list identifiers, so I patched the code to use
> wglShareLists and that fixed the problem.

A far more simple and generic (cross-platform) solution would have been
to split your pipelines just before the vtkActors and/or vtkTextures. 
Then you wouldn't have experienced the display list thrashing that you
were seeing.

> I now understand why list sharing is not used, but I think the current
> implementation is too inefficient.  There are two ways that I can think of
> to fix this situation, one that takes advantage of the list-sharing
> mechanism where available, and one that doesn't:

Actually, it's quite efficient if you use your pipelines more cleverly.
:)

> 1. Using list-sharing:
> 2. Without using list-sharing:

I'm for a combination of these two.  List and context sharing could be
used where it's available and a ring-buffer for display contexts where
sharing is not available.  However, these changes would increase the
complexity of the code to a great extent.  This is definitely not
desirable.

I would be interested to hear the opinion of the VTK
cabal^H^H^H^H^Holdbies. ;)

Thanks,
Charl

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/