[vtk-developers] Interactor freezing on OS X Cocoa

[David Gobbi]

On Mon, Dec 23, 2013 at 11:24 AM, Sean McBride <sean at rogue-research.com> wrote:
> On Mon, 23 Dec 2013 10:58:45 -0700, David Gobbi said:
>
>>The Cocoa Event Handling Guide describes this "event filter" technique
>>as the "The Mouse-Tracking Loop Approach"
>
> I've always preferred what they call "The Three-Method Approach" myself.
> I'm not sure why VTK is the way it is (it wasn't me that did that).  There may
> me some good reason we're not aware of.

I already asked the original author and he said "no particular reason" :)
However, there actually _is_ a very good reason: it ensures that the
mouseDown, mouseDrag, mouseUp sequence is not interrupted by other
events.  However, the vtkInteractorObserver already has a way of dealing
with this: during a drag, one observer captures all input events and decides
what to do with them, instead of those events going to other parts of the
application and perhaps causing conflicting actions.  So, there is no reason
for the vtkCocoaGLView to do anything special.  It just has to relay the
mouse events to VTK and let VTK deal with them.

> I assume you're proposing we switch to the 'The Three-Method Approach'
> technique?

In essence, yes.

> I'd be in favour of that, probably better do merge in after 6.1, as there
> are compatibility issues here.  (Since vtkCocoaGLView is a class users
> likely subclass, changing it will affect subclassers, and so we'd need to
> document this well, etc.)

It'll be documented in the header file.

> Also, I fear your work will conflict with this:
> <http://review.source.kitware.com/#/c/12200/>

I took a quick glance, and no, it shouldn't conflict at all.  Your changes
are to a completely different part of the class.

Also, did you try the example in my original email to see if you can
reproduce the interactor freeze?  It will make it easier for me to push
the improvements through if there is at least _someone_ on the list
who confirms that the freeze problem exists.

  David