On Wed, 31 Oct 2018 at 05:48, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Guille, Hi John, Hi All,
On Tue, Oct 30, 2018 at 2:10 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Guille,

    I'm noticing some lock ups, primarily after resolution changes, or long periods of not in interacting.  I wonder whether there are a class of window events that the loop does not handle and if this produces a lock up, or rather a failure to notice that new events are incoming.  I *think* I have a reproducible case on a MacBookPro whose display resolution is set to "More Space" (see the Displays setting tab). 
Have a VM running on the laptop screen while the laptop is connected to an Apple Cinema display (in this configuration the laptop's retina display reverts to its default resolution).
Then disconnect the cinema display, at which point the MBP's retina display's resolution changes back to :"More Space" and, at least when I tried this morning, the VM locked up.

Guille, I think you're off the hook.  I edited the event loop to include:

        if (!(event.window == 0 || event.window == gDelegateApp.window)){
          printf("breaking with event.window = %lx (gDA.window = %lx)\n", event.window, gDelegateApp.window);

Random thought...
Perhaps when the screen resizes the window bounds are not resized, so for example while the mouse looks like its inside the window, the event coordinates end up outside the window, so the native event dispatching doesn't send the event to the window. It would be interesting to display the bounds-of-the-window together with the event-coordinates and observe how they interact when the screen resolution changes.

cheers -ben