EventLoop in 0.20.0-alpha3 gets clogged on resize events on macos

[lachlansneff]

I was running into this issue on my codebase, but @Osspial suggested I run the window example to see if that gets stuck too. Looking at the printouts from that, when I continuously resize the window, it gets stuck on a bunch of them. When I let go, it continues to render again.

[Osspial]

@francesca64 Got any idea what's going on here? I wouldn't ordinarily ping you, but you wrote the backend and it was really surprising to see this issue come up.

[francesca64]

I'm not sure I understand what's being described? I don't see anything especially scary when resizing the window example.

@Osspial you can ping me as much as you want if you give me a compliment every time.

[lachlansneff]

@francesca64, essentially what's happening in my codebase is that I'm rendering something to the window created by wininit. It should be able to smoothly resize, but it receiving too many resize events in a row and never gets to the EventsCleared event until I let go. Also, the RedrewRequested event never seems to be produced. The window example for me only redraws after I let go when resizing, I think it should be continuously interlacing redraw with resize events.

[Osspial]

From how I read it, @lachlansneff is running into #219 again, except on the latest version of Winit.

and was enshrining you into HALL_OF_CHAMPIONS not enough? :P

[francesca64]

Alright, I think I understand the issue now. I don't have any ideas off the top of my head, especially since it was so long ago.

@Osspial while I adore that kind of lionization, my thirst for attention is infinite.

[Osspial]

@francesca64 Ah, understandable. Still no.

@lachlansneff Actually, I think I know what's going on here. I think I misunderstood what you were saying here, since #219 doesn't quite describe the situation properly. For people reading: the issue isn't that events aren't getting dispatched while a window is resizing; the issue is that just Resize is getting dispatched, and the user isn't receiving EventsCleared or NewEvents whenever the user is resizing the window. That happens because the OS enters a modal loop while resizing happens and the normal logic to determine that the event loop has been cleared doesn't get called. We run into similar issues on Windows, and I don't know why the various windowing API designers decided to do that since it's a major PITA, but it's the situation we're dealing with. This has actually been brought up before here, but I don't recall a dedicated issue being made for it.

On Windows, and we're able to take advantage of the fact that WM_PAINT is always dispatched after all other messages to figure out when the event loop has been cleared during modal resizes. We should be able to adapt that system to macos as long as it has events that exhibit similar properties, and I'd be willing to help whoever tackles that adapt the Windows event loop code to macos, if necessary.

@aleksijuvani @vbogaevsky you two are the main people I'm aware of that have done recent work on the macos backend. Would either of you be able to tackle this?

[ghost]

I think it's a mistake to try to handle this gracefully in the first place. For game-shaped applications it adds a substantial amount of implementation complexity for the tiniest benefit. I keep hearing about people trying to work around this on Windows using timers and all kinds of nonsense and that just seems crazy to me. I'm not familiar with how macOS handles window resizing, so perhaps there is actually a reasonable way to do this there, but skimming through #219 it looks like more of the same.

[Osspial]

@aleksijuvani Winit isn't just for game-shaped applications. Imagine if your text editor or browser or word processor froze completely, or your music player suddenly stopped playing music, every time you resized the window - that leaves a nasty taste in your mouth, and isn't acceptable for reasonable desktop applications.

[ghost]

Turns out this was a really silly thing—all we need to do is to call CFRunLoopAddObserver with kCFRunLoopCommonModes instead of kCFRunLoopDefaultMode. This allows our observer to be invoked during a modal resize loop (or any other modal loop). I've opened #1173 to address this. Please give it a try!