[vtkusers] vtkScalarBarActor & Disappearing actors.

[Ron Inbar]

I'm sorry; I had to check better before I wrote that.

What happened was probably this: 

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

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.

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:

1. Using list-sharing:
The thing that makes my patch unsuitable for submission is that I patched
not only the platform-specific vtkWin32OpenGLRenderWindow but also the
partially-platform-independent vtkOpenGLPolyDataMapper.
Were there a platform-specific vtkWin32OpenGLPolyDataMapper, it could have
taken advantage of wglShareLists by omitting the above test that causes
numerous unnecessary re-compilations of the display list.

2. Without using list-sharing:
Currently the vtkOpenGLPolyDataMapper only remembers the list ID for one
OpenGL context, namely the one in which it last rendered.  In all other
contexts, immediate rendering is used, which is very slow.  A table could be
added that records the list ID for every context in which the mapper ever
rendered, and allows it to use the appropriate one.  Should the list change,
all contexts should be marked as "dirty", and this status should be cleared
only after the list is re-compiled in that context.

Ron



-----Original Message-----
From: Charl P. Botha [mailto:c.p.botha at its.tudelft.nl] 
Sent: Monday, March 10, 2003 9:45 PM
To: Ron Inbar
Cc: vtkusers at public.kitware.com
Subject: Re: [vtkusers] vtkScalarBarActor & Disappearing actors.

On Mon, Mar 10, 2003 at 07:42:58PM +0200, Ron Inbar wrote:
> different vtkRenderWindows, you will end up with two display lists, which,
> most probably, will not have the same identifier.  But
> vtkOpenGLPolyDataMapper assumes (incorrectly) that the same identifier
will
> work every time, so sometimes it attempts to render a display list using
an
> identifier from the wrong context.  This usually leads to the wrong object

  if ( this->GetMTime() > this->BuildTime ||
       input->GetMTime() > this->BuildTime ||
       act->GetProperty()->GetMTime() > this->BuildTime ||
       ren->GetRenderWindow() != this->LastWindow)
    {

The above code is an extract from vtkOpenGLPolyDataMapper.cxx and shows that
this class DOES check for a changed RenderWindow.  In this case, it
re-generates display lists.

If you can point out more specifically where you believe this doesn't
happen, I would be most grateful.  Let's try and fix these problems (if they
exist) first.

> popping up in the window, and in other cases to objects disappearing.
> OpenGL has a ready-made solution to this problem: there is a mechanism
that
> enables all contexts (i.e., windows) to share the same display lists and
to
> identify them using the same numbers.  The only trouble is that VTK, for
> reasons unknown to me, doesn't use this list-sharing mechanism.
> 
> I successfully patched VTK 3.1 to fix this bug.  As soon as I find some
free
> time I will do the same for VTK 4.x, and then I'll send you the patched
> sources.  I hope they will make it into the next release.

I would be more careful with that word.  NOT making use of shared contexts
is NOT a bug, although I do agree that utilising shared contexts is a very
useful feature.  The problem is that shared contexts is not available on all
GL implementations, so one would have to do careful checking in the code.

-- 
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.