[vtkusers] Moving an actor, after about 1.5 hours.

[Ken Martin]

To expand and guess a bit, there is code in vtkOpenGLActor ala

void vtkOpenGLActor::GetKeyMatrices(vtkMatrix4x4 *&mcwc, vtkMatrix3x3
*&normMat)
{
  // has the actor changed?
  if (this->GetMTime() > this->KeyMatrixTime)
    {
    this->ComputeMatrix();

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.

Thanks
Ken






On Mon, Mar 7, 2016 at 9:11 AM, Richard Frank <rickfrank at me.com> wrote:

> Ken Martin said previously
>
> "Doubling the size would increase the run time by a factor of 4.3 billion
> o.O"
>
>
>
> Sent from my iPad
>
> On Mar 7, 2016, at 9:07 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>
> On Mon, Mar 7, 2016 at 6:43 AM, Richard Frank <rickfrank at me.com> wrote:
>
>>
>> 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.
>>
>
> 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).
>
> 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.....
>>
>
> 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.
>
>
>> Also, why the runtime hit on a 64 bit build?.
>>
>
> What are you referring to? (I rarely use Windows, and when I do, I use
> 32-bit builds).
>
>  - David
>
>


-- 
Ken Martin PhD
Chairman & CFO
Kitware Inc.
28 Corporate Drive
Clifton Park NY 12065
518 371 3971

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160307/d83dcdbc/attachment.html>