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

Thu Mar 10 09:25:11 EST 2016

I was able to reproduce it ( fortunately we have a playback mechanism) and it seems to be reproducible on demand as the actors look to be in the same resting position each time. 

The MTime for the actor and its matrix were well below max int32.

But we do notice the the screen " flashes " just as it happens. Not sure if it's the whole screen, as our Qt main window is maximized and it happens very fast, or just the render areas.

Our actors are updated by our code ( not the MTime)  somewhere greater than 83000 times at that point. I'm hoping to narrow down the time to be debuggable- let me know if anyone has any thought about the "flash". The flash  happens on two different machines with 2 different Nvidia cards. Somewhere around 1-2 hours in ( but seems to be repeatable at exactly some time in that range, just hard to catch it without staring at a stop watch for an hour)

Thanks 

Rick

Sent from my iPadm

> On Mar 8, 2016, at 8:47 AM, David Gobbi <david.gobbi at gmail.com> wrote:
> 
> Hi Richard,
> 
> Since only the low 32 bits are kept (the high bits are simply discarded), the wrap-around of the ModifiedTime is exactly the same as if a 32-bit unsigned integer was being incremented.
> 
>  - David
> 
>> On Tue, Mar 8, 2016 at 6:27 AM, Richard Frank <rickfrank at me.com> wrote:
>> Actually, it's a bit stranger than I thought. The global time stamp on Windows 64 bit is a 64 bit int cast to an 
>> Unsigned long, as size of void ptr is 8
>> void vtkTimeStamp::Modified()
>> {
>> #if VTK_SIZEOF_VOID_P == 8
>> static vtkAtomicInt64 GlobalTimeStamp(0);
>> #else
>> static vtkAtomicInt32 GlobalTimeStamp(0);
>> #endif
>> this->ModifiedTime = (unsigned long)++GlobalTimeStamp;
>> }
>> 
>> I'm not certain off the top of my head what the wrap around pattern would be - probably 2 times around before wrapping to zero....
>> 
>> 
>> Sent from my iPad
>> 
>>> On Mar 7, 2016, at 11:13 AM, David Cole <DLRdave at aol.com> wrote:
>>> 
>> 
>>> This is a well known issue, reported here:
>>> 
>>>    http://www.vtk.org/Bug/view.php?id=14310
>>> 
>>> There are some patch files against older versions of VTK which are
>>> attached to the bug. You could try a similar patch (although it's
>>> quite a few lines to change) against whatever version of VTK you are
>>> using.
>>> 
>>> I would be VERY interested in seeing a modification to fix this
>>> problem make its way into VTK master.
>>> 
>>> 
>>> David C.
>>> 
>>> 
>>>> On Mon, Mar 7, 2016 at 9:36 AM, Ken Martin <ken.martin at kitware.com> wrote:
>>>> Oops, yes, I meant runnable time not run time :-)
>>>> 
>>>> 
>>>> 
>>>>> On Mon, Mar 7, 2016 at 9:25 AM, Richard Frank <rickfrank at me.com> wrote:
>>>>> 
>>>>> Oh never mind - increase the runnable time not run time :>}
>>>>> 
>>>>> 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
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Powered by www.kitware.com
>>>>> 
>>>>> Visit other Kitware open-source projects at
>>>>> http://www.kitware.com/opensource/opensource.html
>>>>> 
>>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>>> 
>>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>>> 
>>>>> Follow this link to subscribe/unsubscribe:
>>>>> http://public.kitware.com/mailman/listinfo/vtkusers
>>>> 
>>>> 
>>>> 
>>>> --
>>>> 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.
>>>> 
>>>> _______________________________________________
>>>> Powered by www.kitware.com
>>>> 
>>>> Visit other Kitware open-source projects at
>>>> http://www.kitware.com/opensource/opensource.html
>>>> 
>>>> Please keep messages on-topic and check the VTK FAQ at:
>>>> http://www.vtk.org/Wiki/VTK_FAQ
>>>> 
>>>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>>> 
>>>> Follow this link to subscribe/unsubscribe:
>>>> http://public.kitware.com/mailman/listinfo/vtkusers
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160310/0ab119f2/attachment.html>