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

[Richard Frank]

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