[vtk-developers] Interactor freezing on OS X Cocoa

David Gobbi david.gobbi at gmail.com
Mon Dec 23 12:58:45 EST 2013


This is something I've brought up before, but no-one has confirmed.

In OS X, if you compile VTK with Cocoa and run one of the simple
interactor examples (like Cone5), it is easy to get the interactor to
lock up with the following actions:

1) Click in the window.
2) Drag the mouse in the window.
3) Before releasing the first mouse button, press another mouse
button, and continue to drag.
4) Release both mouse buttons.
5) Try interacting again: the interactor has frozen.

The reason this occurs is because of the way that Cocoa mouse events
are handled in vtkCocoaGLView.  When the mouse is dragged, all other
events are filtered out and delayed until the drag has completed.
When the drag completes, the delayed events are played out over the
following event-loop cycles in way that isn't completely predictable:
the interactor is locked for a while when you first interact, then it
seems to process old events instead of new events, and finally after
long while it starts behaving properly again.

The Cocoa Event Handling Guide describes this "event filter" technique
as the "The Mouse-Tracking Loop Approach" because the mouse
essentially takes over the tracking loop until the drag is complete.
It says explicitly that, in order to work well, there has to be some
added logic to figure out whether filtered events are delayed or
simply discarded.  Personally, I think it is just the wrong approach
altogether.  On all other systems (X, Win32, Carbon) all events are
simply passed through to VTK... no filtering is performed.  Would
anyone object if I modified the Cocoa code so that it does the same?
Having VTK receive the events out-of-order simply seems wrong.

  David



More information about the vtk-developers mailing list