<div dir="ltr">Hello,<br><br>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 :<br><br><a href="http://www.vtk.org/Bug/view.php?id=7111">http://www.vtk.org/Bug/view.php?id=7111</a><br>
<br>If you are going to improve the display list recompilation rules, can you please fix it at the same time ?<br><br>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.<br>
<br>Thanks.<br><br><div class="gmail_quote">2008/7/24 Francois Bertel <span dir="ltr"><<a href="mailto:francois.bertel@kitware.com">francois.bertel@kitware.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm gonna revert back the order of painters for now.<br>
<br>
[LONG PART starts here]<br>
<br>
The problem is the current implementation of the display list painter<br>
makes some assumptions about what kind of delegate it can have.<br>
Hence this 8-line conditional statement to decide to rebuild the<br>
display list or not.<br>
<br>
A long term solution I can think of to address this issue would be to<br>
add a new method in vtkPainter called "virtual bool<br>
NeedUpdate(...)=0;"<br>
This pure virtual method (with the same arguments of RenderInternal )<br>
will tell if the painter (and recursively its own delegates) needs to<br>
be re-rendered in the case of the use of display lists.<br>
<br>
At the end, part of the implementation of RenderInternal() of the<br>
display list painter would look like:<br>
<br>
if(this->NeedUpdate(...)))<br>
 {<br>
  // rebuild the list.<br>
  // ...<br>
 this->Superclass::RenderInternal(renderer, actor, typeflags, true);<br>
// true for forceCompileOnly<br>
  // ...<br>
 }<br>
if(!forceCompileOnly)<br>
{<br>
 // call the list<br>
}<br>
...<br>
<br>
its NeedUpdate() will look like:<br>
{<br>
return this->DisplayListId==0 || (this->Delegate!=0 &&<br>
this->Delegate->NeedUpdate(...));<br>
}<br>
<br>
and for each other sub-class of vtkPainter, NeedUpdate() would be the following:<br>
<br>
bool NeedUpdate(...)<br>
{<br>
 bool result;<br>
<br>
 // figure out if I need to rerender (assuming this painter need the<br>
property on the actor)<br>
 result=actor->GetProperty()->GetMTime() > this->BuildTime;<br>
<br>
// what about my own delegate?<br>
 if(!result)<br>
  {<br>
  result=this->Delegate!=0 && this->Delegate->NeedUpdate(...);<br>
  }<br>
 return result;<br>
<div><div></div><div class="Wj3C7c">}<br>
<br>
On Thu, Jul 24, 2008 at 12:46 PM, Francois Bertel<br>
<<a href="mailto:francois.bertel@kitware.com">francois.bertel@kitware.com</a>> wrote:<br>
> The problem is there is no modification time specific to a part of the<br>
> actor (in this case, the transform and ivar modifiying it are part of<br>
> the vtkProp3D (superclass of vtkActor)).<br>
><br>
> On Thu, Jul 24, 2008 at 12:38 PM, Jeff Baumes <<a href="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a>> wrote:<br>
>> I've seen this issue before where textures were being reloaded every<br>
>> frame because someone had added a<br>
>><br>
>> || this->Renderer->MTime() > blah<br>
>><br>
>> to the if statement for reloading the texture, and the renderer was<br>
>> actually being modified every frame. It looks like in this case it is<br>
>> really just a specific part of the vtkActor that Francios is checking<br>
>> for modification. Something in the actor is changing in your program<br>
>> every frame, but not the part of the actor that should really make<br>
>> that "if" pass. The condition should probably be more restrictive and<br>
>> only pass if certain parts of the actor are modified.<br>
>><br>
>> Jeff<br>
>><br>
>><br>
>> On Thu, Jul 24, 2008 at 12:22 PM, Mathieu Coursolle<br>
>> <<a href="mailto:mcoursolle@rogue-research.com">mcoursolle@rogue-research.com</a>> wrote:<br>
>>> Hi,<br>
>>><br>
>>> I've track down the source of the problem to this change:<br>
>>><br>
>>> <a href="http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLDisplayListPainter.cxx?r1=1.7&r2=1.8" target="_blank">http://public.kitware.com/cgi-bin/viewcvs.cgi/Rendering/vtkOpenGLDisplayListPainter.cxx?r1=1.7&r2=1.8</a><br>

>>><br>
>>> For some reason, if I undo this single change, it is rendering as fast as<br>
>>> before.<br>
>>><br>
>>> Anybody knows what the problem might be?<br>
>>><br>
>>> Thanks!<br>
>>><br>
>>> Mathieu<br>
>>><br>
>>><br>
>>><br>
>>> On 24-Jul-08, at 11:07 AM, Mathieu Coursolle wrote:<br>
>>><br>
>>>> Hi vtk-dev,<br>
>>>><br>
>>>> I am developing a Cocoa application on Mac OSX 10.5 based on VTK.<br>
>>>> I usually update from CVS once in a while to have the recent fixes<br>
>>>> and features.<br>
>>>><br>
>>>> I updated yesterday and rendering a vtkPolyData is now very slow.<br>
>>>> It use to be quite fast with my 2 weeks old version.<br>
>>>><br>
>>>> I used the Shark tool to check in which part of the code it was spending<br>
>>>> all<br>
>>>> this time, and it resulted in the OpenGL API.<br>
>>>><br>
>>>> Any idea of which last days commit might have cause this?<br>
>>>><br>
>>>> Thanks!<br>
>>>><br>
>>>> Mathieu<br>
>>>> _______________________________________________<br>
>>>> vtk-developers mailing list<br>
>>>> <a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
>>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
>>>><br>
>>><br>
>>> _______________________________________________<br>
>>> vtk-developers mailing list<br>
>>> <a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
>>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Jeff Baumes, Ph.D.<br>
>> R&D Engineer, Kitware Inc.<br>
>> (518) 371-3971 x132<br>
>> <a href="mailto:jeff.baumes@kitware.com">jeff.baumes@kitware.com</a><br>
>> _______________________________________________<br>
>> vtk-developers mailing list<br>
>> <a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
>> <a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
>><br>
><br>
><br>
><br>
> --<br>
> François Bertel, PhD | Kitware Inc. Suite 204<br>
> 1 (518) 371 3971 x113 | 28 Corporate Drive<br>
>  | Clifton Park NY 12065, USA<br>
><br>
<br>
<br>
<br>
--<br>
François Bertel, PhD | Kitware Inc. Suite 204<br>
1 (518) 371 3971 x113 | 28 Corporate Drive<br>
 | Clifton Park NY 12065, USA<br>
_______________________________________________<br>
vtk-developers mailing list<br>
<a href="mailto:vtk-developers@vtk.org">vtk-developers@vtk.org</a><br>
<a href="http://www.vtk.org/mailman/listinfo/vtk-developers" target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Julian Ibarz<br>
</div>