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

Thu Mar 10 12:06:51 EST 2016

As noted in one of the comments I made in the bug I referenced earlier (
http://www.vtk.org/Bug/view.php?id=14310) ... you can force it to happen
quickly if it is related to VTK MTime overflow with a modification like
this to the VTK source code:

//-------------------------------------------------------------------------
#define CALLS_UNTIL_OVERFLOW 200

//-------------------------------------------------------------------------
void vtkTimeStamp::Modified()
{
#if VTK_SIZEOF_VOID_P == 8
  static vtkAtomicInt<vtkTypeInt64> GlobalTimeStamp(0xffffffffffffffffULL -
CALLS_UNTIL_OVERFLOW);
#else
  static vtkAtomicInt<vtkTypeInt32> GlobalTimeStamp(0xffffffff -
CALLS_UNTIL_OVERFLOW);
#endif

Adjust CALLS_UNTIL_OVERFLOW to some smallish number that represents a few
seconds or minutes of running your app, and then you should see the effects
of overflow within seconds or minutes instead of waiting more than an hour.

In our app, we've seen VTK MTimes go up by as much as 1.7 million per
second in the Release build. (Which, in and of itself, is fairly
impressive... ;-)

HTH,
David C.

On Thu, Mar 10, 2016 at 9:25 AM, Richard Frank <rickfrank at me.com> wrote:

> 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
>>
>>
>>
>
> _______________________________________________
> 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/5ca6c4f5/attachment.html>