[vtk-developers] Performance slow down

[Julian Ibarz]

Hello,

There is another problem to the verification state of the display list : it
is always recompiled after a selection rendering. I filed a bug report :

http://www.vtk.org/Bug/view.php?id=7111

If you are going to improve the display list recompilation rules, can you
please fix it at the same time ?

The patch proposed in the bug report is not clean but it's the only way I
found with the actual conception of VTK. The problem is that the display
list is not recompiled if we modify something between the last rendering and
the rendering selection, a temporal solution is to be sure to call a normal
rendering after a modification before calling a selection rendering and all
works fine.

Thanks.

2008/7/24 Francois Bertel <francois.bertel at kitware.com>

> I'm gonna revert back the order of painters for now.
>
> [LONG PART starts here]
>
> The problem is the current implementation of the display list painter
> makes some assumptions about what kind of delegate it can have.
> Hence this 8-line conditional statement to decide to rebuild the
> display list or not.
>
> A long term solution I can think of to address this issue would be to
> add a new method in vtkPainter called "virtual bool
> NeedUpdate(...)=0;"
> This pure virtual method (with the same arguments of RenderInternal )
> will tell if the painter (and recursively its own delegates) needs to
> be re-rendered in the case of the use of display lists.
>
> At the end, part of the implementation of RenderInternal() of the
> display list painter would look like:
>
> if(this->NeedUpdate(...)))
>  {
>  // rebuild the list.
>  // ...
>  this->Superclass::RenderInternal(renderer, actor, typeflags, true);
> // true for forceCompileOnly
>  // ...
>  }
> if(!forceCompileOnly)
> {
>  // call the list
> }
> ...
>
> its NeedUpdate() will look like:
> {
> return this->DisplayListId==0 || (this->Delegate!=0 &&
> this->Delegate->NeedUpdate(...));
> }
>
> and for each other sub-class of vtkPainter, NeedUpdate() would be the
> following:
>
> bool NeedUpdate(...)
> {
>  bool result;
>
>  // figure out if I need to rerender (assuming this painter need the
> property on the actor)
>  result=actor->GetProperty()->GetMTime() > this->BuildTime;
>
> // what about my own delegate?
>  if(!result)
>  {
>  result=this->Delegate!=0 && this->Delegate->NeedUpdate(...);
>  }
>  return result;
> }
>
> On Thu, Jul 24, 2008 at 12:46 PM, Francois Bertel
> <francois.bertel at kitware.com> wrote:
> > The problem is there is no modification time specific to a part of the
> > actor (in this case, the transform and ivar modifiying it are part of
> > the vtkProp3D (superclass of vtkActor)).
> >
> > On Thu, Jul 24, 2008 at 12:38 PM, Jeff Baumes <jeff.baumes at kitware.com>
> wrote:
> >> I've seen this issue before where textures were being reloaded every
> >> frame because someone had added a
> >>
> >> || this->Renderer->MTime() > blah
> >>
> >> to the if statement for reloading the texture, and the renderer was
> >> actually being modified every frame. It looks like in this case it is
> >> really just a specific part of the vtkActor that Francios is checking
> >> for modification. Something in the actor is changing in your program
> >> every frame, but not the part of the actor that should really make
> >> that "if" pass. The condition should probably be more restrictive and
> >> only pass if certain parts of the actor are modified.
> >>
> >> Jeff
> >>
> >>
> >> On Thu, Jul 24, 2008 at 12:22 PM, Mathieu Coursolle
> >> <mcoursolle at rogue-research.com> wrote:
> >>> Hi,
> >>>
> >>> I've track down the source of the problem to this change:
> >>>
> >>>
> http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLDisplayListPainter.cxx?r1=1.7&r2=1.8
> >>>
> >>> For some reason, if I undo this single change, it is rendering as fast
> as
> >>> before.
> >>>
> >>> Anybody knows what the problem might be?
> >>>
> >>> Thanks!
> >>>
> >>> Mathieu
> >>>
> >>>
> >>>
> >>> On 24-Jul-08, at 11:07 AM, Mathieu Coursolle wrote:
> >>>
> >>>> Hi vtk-dev,
> >>>>
> >>>> I am developing a Cocoa application on Mac OSX 10.5 based on VTK.
> >>>> I usually update from CVS once in a while to have the recent fixes
> >>>> and features.
> >>>>
> >>>> I updated yesterday and rendering a vtkPolyData is now very slow.
> >>>> It use to be quite fast with my 2 weeks old version.
> >>>>
> >>>> I used the Shark tool to check in which part of the code it was
> spending
> >>>> all
> >>>> this time, and it resulted in the OpenGL API.
> >>>>
> >>>> Any idea of which last days commit might have cause this?
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Mathieu
> >>>> _______________________________________________
> >>>> vtk-developers mailing list
> >>>> vtk-developers at vtk.org
> >>>> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>>
> >>>
> >>> _______________________________________________
> >>> vtk-developers mailing list
> >>> vtk-developers at vtk.org
> >>> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>>
> >>
> >>
> >>
> >> --
> >> Jeff Baumes, Ph.D.
> >> R&D Engineer, Kitware Inc.
> >> (518) 371-3971 x132
> >> jeff.baumes at kitware.com
> >> _______________________________________________
> >> vtk-developers mailing list
> >> vtk-developers at vtk.org
> >> http://www.vtk.org/mailman/listinfo/vtk-developers
> >>
> >
> >
> >
> > --
> > François Bertel, PhD | Kitware Inc. Suite 204
> > 1 (518) 371 3971 x113 | 28 Corporate Drive
> >  | Clifton Park NY 12065, USA
> >
>
>
>
> --
> François Bertel, PhD | Kitware Inc. Suite 204
> 1 (518) 371 3971 x113 | 28 Corporate Drive
>  | Clifton Park NY 12065, USA
> _______________________________________________
> vtk-developers mailing list
> vtk-developers at vtk.org
> http://www.vtk.org/mailman/listinfo/vtk-developers
>



-- 
Julian Ibarz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20080725/6f3fcfe0/attachment.html>