Calling request_redraw() inside RedrawRequested callback has platform-dependent effect

[mcclure]

I have a small example program (must use commit 77b3065ba to see problem) here based on the wgpu crate's examples. It is meant to display a simple animated graphical demo. It uses winit.

In order to animate, I call window.request_redraw() in the Resized event handler (which always fires at boot), and also at the end of the RedrawRequested event handler (in other words each frame ends by requesting another frame).

Expected behavior: I expect that calling window.request_redraw() in this way at the end of RedrawRequested will do some specific, predictable thing*. I don't care what.

Observed behavior: Testing on Mac OS 10.13, I see continuous animation at what appears to be the monitor refresh rate. Testing on Windows 10, I do not see animation. It draws frames on window resize (including window init) and at no other time. On

I now understand that the "correct" way to continuously animate is to request ControlFlow::Poll [instead of Wait] and then call window.request_redraw() in my RedrawEventsCleared handler. But it took me longer to figure this out than it should have due to my "incorrect"(?) method above seeming to work (until I tried it on Windows).

Notes:

• The example code above uses winit 0.29.0-beta.0. However I did a test with winit 0.28.6 and got the same results on both platforms.
• This problem may be related to Fix redraws not being scheduled correctly on macOS and iOS #2640 . However that bug seems to be about RequestRedraw triggering "extra" times on MacOS and for me RequestRedraw is not triggering for no reason, it triggers specifically in response to me issuing a request_redraw (and if I remove the request_redraw in RequestRedraw the animation does not occur).

* Predictably doing nothing is also OK.

[kchibisov]

See #2412 and #2900