[vtkusers] vtkScalarBarActor & Disappearing actors.

[Ron Inbar]

1. True, I shared both actors and textures.  That's because I wanted to see
exactly the same view from two different viewpoints.  If I split the
pipeline I would need to send every change to each actor separately.

2. Under the current architecture, as I understand it, you need to split the
pipeline before the *mapper* (i.e., define different mappers for each
window).  If you only split the actor it will still perform poorly.

Ron

-----Original Message-----
From: Charl P. Botha [mailto:c.p.botha at its.tudelft.nl] 
Sent: Tuesday, March 11, 2003 12:23 PM
To: Ron Inbar
Cc: vtkusers at public.kitware.com
Subject: RE: [vtkusers] vtkScalarBarActor & Disappearing actors.

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/

This e-mail message has been sent by MediGuide
and is for the use of the intended recipients only.
The message may contain privileged or confidential information .
If you are not the intended recipient you are hereby notified that any use,
distribution or copying of this communication is strictly prohibited,
and you are requested to delete the e-mail and any attachments
and notify the sender immediately.