<div dir="ltr">To expand and guess a bit, there is code in vtkOpenGLActor ala<div><br></div><div><div>void vtkOpenGLActor::GetKeyMatrices(vtkMatrix4x4 *&mcwc, vtkMatrix3x3 *&normMat)</div><div>{</div><div> // has the actor changed?</div><div> if (this->GetMTime() > this->KeyMatrixTime)</div><div> {</div><div> this->ComputeMatrix();</div><div><br></div><div>This code only recomputes the matrices when something has changed. When you change the actor, its MTime goes up. That code then recomputes the matrix and KeyMatrixTime goes up. Everything is fine as long as those two numbers keep climbing up together. But if GetMTime were suddenly to roll over and go to a small number while KeyMatrixTime was at a really high number. Then the if statement fails and the matrix gets stuck with an old value. Each extra bit on the mtime doubles how high it can grow before rolling back over to zero. At 64bits it would take tens or hundreds of years of constant execution before it rolled over.</div><div><br></div><div>Thanks</div><div>Ken</div><div><br></div><div><br></div><div><br></div><div><br></div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 7, 2016 at 9:11 AM, Richard Frank <span dir="ltr"><<a href="mailto:rickfrank@me.com" target="_blank">rickfrank@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Ken Martin said previously </div><div><br></div><div>"<span style="background-color:rgba(255,255,255,0)">Doubling the size would increase the run time by a factor of 4.3 billion o.O"</span></div><div><br></div><div><br><br>Sent from my iPad</div><div><br>On Mar 7, 2016, at 9:07 AM, David Gobbi <<a href="mailto:david.gobbi@gmail.com" target="_blank">david.gobbi@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 7, 2016 at 6:43 AM, Richard Frank <span dir="ltr"><<a href="mailto:rickfrank@me.com" target="_blank">rickfrank@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><br>Not yet. That will be next step. Seems plausible since I can't find after quite a bit of testing any leaks, OpenGL errors reported, and testing on different systems with different Nvidia cards. etc, and tracing into VTK ( although trying to trace through all the calls to executive, algorithm, superclass, etc is quite cumbersome). Things just fail to move, silently.</div></div></blockquote><div><br></div><div>As far as I'm aware, the only reason that VTK hasn't yet switched to a 64-bit MTime everywhere is that there would be backwards compatibility problems (GetMTime is a virtual method that is overridden in many subclasses).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>I found another post where someone had a slightly similar problem and said removing and re-adding actors fixed the problem, which we also seem to see.....</div></div></blockquote><div><br></div><div>The VTK pipeline uses the difference between timestamps to as an indicator for when to undertake certain actions. So it is likely that problems only arise when this "difference" between two crucial timestamps exceeds the 32-bit limit. That's why re-adding actors might fix the problem.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>Also, why the runtime hit on a 64 bit build?.</div></div></blockquote><div><br></div><div>What are you referring to? (I rarely use Windows, and when I do, I use 32-bit builds).</div><div><br></div><div> - David </div></div></div></div>
</div></blockquote></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ken Martin PhD<div>Chairman & CFO<br>Kitware Inc.<br>28 Corporate Drive<br>Clifton Park NY 12065<br>518 371 3971<div><br></div><div><span style="font-size:10pt;font-family:Tahoma,sans-serif">This communication,
including all attachments, contains confidential and legally privileged
information, and it is intended only for the use of the addressee. Access to this email by anyone else is
unauthorized. If you are not the intended recipient, any disclosure, copying,
distribution or any action taken in reliance on it is prohibited and may be
unlawful. If you received this communication in error please notify us
immediately and destroy the original message.
Thank you.</span></div></div></div>
</div>