[vtkusers] Moving an actor, after about 1.5 hours.
David Gobbi
david.gobbi at gmail.com
Mon Mar 7 09:07:39 EST 2016
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/e4d1a2c6/attachment.html>
More information about the vtkusers
mailing list