Fix requested repaints not causing Bevy to redraw.

[andriyDev]

The previous implementation seems to have lost track of what the redraw was supposed to be tracking. This meant button clicks would not trigger a redraw on WinitSettings::desktop_app() (only a mouse move after would cause a redraw).

I've tested this on my own project and things work much more correct!

Fixes #239.

[aevyrie]

It looks like the correct solution is to use this field from egui's FullOutput: https://docs.rs/egui/latest/egui/viewport/struct.ViewportOutput.html#structfield.repaint_delay
and find if any viewport wants a repaint. Even better, use bevy's winit proxy to schedule the exact wakeup time based on the minimum repaint delay.

It appears this was mangled during the last release.

[aevyrie]

Although I noted another "better" solution, this change is an improvement that fixes a regression, and matches the original implementation.

[andriyDev]

It looks like the correct solution is to use this field from egui's FullOutput: https://docs.rs/egui/latest/egui/viewport/struct.ViewportOutput.html#structfield.repaint_delay and find if any viewport wants a repaint. Even better, use bevy's winit proxy to schedule the exact wakeup time based on the minimum repaint delay.

As far as I can tell, viewports don't actually know if they need a redraw or not. As in "request redraw" only applies to the whole context (so all viewports). That said I agree that the best solution also takes into account the redraw_delay as you noted.

My point being: this PR will not need to be reverted or rewritten, just more code will need to be added to fully handle all the cases.

[vladbat00]

Thank you for the fix! I'm good to merge it as is, at least that will fix the immediate regression. If anyone wants to submit a PR with a proper fix, I'll gladly accept it as well (I don't have the time to look into that myself, unfortunately).