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

[David Gobbi]

Hi Richard,

Did you confirm that the MTime overflow is what is causing your software to
fail?
Also, what Ken said.

 - David

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

> Hi David,
>
> A bit of looking at the documentation shows vtkTimeStamp having an
> unsigned long monotonically increasing, which on Windows 64 bit is 32 bits.
>
> A seemingly "simple" work around for us would seem to be to redefine the
> mvar to be a uint64_t and rebuild VTK. That would seem to double the time
> length.
>
> But I wonder then why this wasn't done before? There must be some unwanted
> side effects? Possible memory issues ( points having their own
> vtkTimeStamp)?
>
> Thanks
>
> Rick
>
>
> Sent from my iPad
>
> On Mar 6, 2016, at 10:18 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>
> Is this on Windows?  VTK uses a 32-bit global MTime on Windows.  Call
> GetMTime() on your actor to see if the MTime is approaching the limit.  If
> you find that the MTime overflow is indeed the problem, then complain.
> Complain loudly.  The MTime issue has been in the bugtracker for years.
>
>  - David
>
> On Sun, Mar 6, 2016 at 7:56 PM, Richard Frank <rickfrank at me.com> wrote:
>
>> We are moving an actor(s) (  assemblies ) in multiple QtViews that
>> represent a set of surgical tools.
>>
>> In one of our unit tests, the tools are moved for approximately 1 - 1.5
>> hours and after that time period the tools no longer " move" during
>> rendering, even though different position data is being set to them via
>> SetUserTranform.
>>
>> There are, as far as we can tell; no reported memory leaks; no memory
>> overwrites, and no reported OpenGL errors. When I trace into vtkOpenGLActor
>> nothing appears to be amiss. This is on two different machines one with a
>> quadro 5000m and the other with a high end geoforce card.
>>
>> If we use a keystroke to remove and add the actors back into the
>> renderer, this will usually fix the problem, but we want to get to the root
>> cause.
>>
>> I'd appreciate any tips on how to debug this.
>>
>>
>> Thanks
>> Rick
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160307/0faab6ba/attachment.html>