Resize events not working on OSX

[bvssvni]

OSX 10.9.5

It seems resize events are not received.

https://github.com/PistonDevelopers/glutin_window/blob/master/src/lib.rs#L89

The glutin_window back-end should map this correctly, but it is not receiving any events for resize.

[bvssvni]

Confirmed. Overriding glutin_window and printing out other events works, but not resize events.

[bvssvni]

Just posting this here for tracking PistonDevelopers/gfx_graphics#208

[fkaa]

This boils down to whether or not window resizes should be "live" (sent immediately), only used through the callback function, or lastly, deferred until resize is over (only one resize event per window resize).

cc @tomaka

[tomaka]

I hate this callback, but apparently resize events are shitty on os/x if you don't use a callback.

[fkaa]

Personally I prefer deferred resize event to a callback. Maybe this is related to #245, as resizing blocks the run loop?

[glennw]

Servo needs live resize support. I don't like the callback either, but I'm not aware of any way to do live resizing on mac without it. I'm no mac expert though - if there's a way to do live resize without the callback that would be great.

[fkaa]

If this involves moving the window and application code into separate threads I'd say it would be out of scope for glutin. I'm assuming servo will eventually write its own window backend for each platform, since just a OpenGL context wont cut it in the long run.

For now I think the callback function will do, but what should be done with the Resize event?

[bvssvni]

Perhaps we could check the size in the event iterators and generate a Resize event if the window size is changed?

[Gankra]

This is still an issue -- but just checking the current window.draw_size() on every iteration is indeed sufficient to work around this. Only triggers resize on release on OSX.

e.g.

        let cur_win_size = e.draw_size();
        let (cur_win_w, cur_win_h) = (cur_win_size.width, cur_win_size.height);

        if cur_win_w != win_w || cur_win_h != win_h {
            view_info = compute_view(pixel_scale, cur_win_w, cur_win_h, target_w, target_h);
            win_w = cur_win_w; 
            win_h = cur_win_h;
        }

[mitchmindtree]

Just came across this, definitely a pity to have to use the callback.

Some more related issues and further reading for anyone interested:

• Window not being redrawn while resizing openframeworks/openFrameworks#2456
• Window resizing causes event processing to block glfw/glfw#1
• Window live resizing example glfw/glfw#424 (reference)
• Main Thread Freezes on Window Resizing glfw/glfw#472
• http://www.cocoabuilder.com/archive/cocoa/180283-problem-redrawing-views-while-window-resize-button-is-held.html
• https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CocoaPerformance/Articles/CocoaLiveResize.html

[mitchmindtree]

@bvssvni @gankro Even if we can generate our own Resized events by tracking the size of the window manually in the PollEventsIterator and WaitEventsIterator, the iterators themselves will still become blocked when the window begins dragging anyway, so the resize still won't emit until the end of the drag. I guess that's still better than no Resize events at all which is currently the case, however I'd like to have a go at seeing if we can get live Resized events happening so we can ditch the callback altogether.

There's a comment here that describes how this might be possible by subclassing NSApplication and overriding nextEventMatchingMask:untilDate:inMode:dequeue::

You can probably do it, but it will be very messy.

Many of the controls track the mouse by grabbing control at mouse
down and then polling for mouseDragged and mouseUp by calling:

-[NSWindow nextEventMatchingMask:]

The widow resize isn't doing that. A mouse down on the resize corner
starts polling NSApp directly by calling:

-[NSApp nextEventMatchingMask:untilDate:inMode:dequeue:]

with a mask of 68 (NSLeftMouseUpMask | NSLeftMouseDraggedMask).

This then blocks waiting for a left mouse drag or up. When it does
get a drag, it does the resize and polls again.

(I have instrumented versions of NSApplication and NSWindow with lots
of logging.)

So... you might be able to something very ugly along the lines of:

• Subclass NSApplication and override -[NSApp
  nextEventMatchingMask:untilDate:inMode:dequeue:]
• Determine through whatever combination of overrides and flags that
  you are here because you've pushed the mouse button on the resize
  handle.
• Call drawRect on your view yourself and flush the window yourself.
• Post an NSApplicationDefined event to the queue
• Change the mask to include NSApplicationDefined and call super
• When the call to super finally returns check the event type. If it
  is a drag or up, return. Otherwise do the drawing manually again,
  post another event, and call super again. You might want to put a
  small sleep in there to avoid churning.

This comment describes how to redraw upon resize, however it seems like we might be able to do something similar to avoid blocking our event iterator and continue emitting events. For example, we could catch mouse presses that occur over the resizable edges and rather than having the NSApplication enter its own nextEventMatchingMask:untilDate:inMode:dequeue: loop for the duration of the resize, we track the resize ourself using mouse moved, post our own resize events to the application and in turn avoid blocking.

[tomaka]

Closing for rust-windowing/winit#39