Throttle RedrawRequested

[kchibisov]

Fixes #2412.

• macOS (broken drawRect, DisplayLink?)
• Windows (WM_PAINT?)
• Wayland (frame callbacks)
• web (requestAnimationFrame)
• fallback (X11, redox) (timer based with global timer seed)

The docs are also not updated and it would be nice to have software example showing FPS it's rendering it right now.

--

Wayland done and it works.

[kchibisov]

That's basically what I'm using for testing now https://github.com/kchibisov/glutin/tree/test-winit.

Similar changes could be done to example/window(it'll need a way to request_redraw.

[rib]

I think it could be good to focus on one platform at a time with updating how RedrawRequested is throttled.

So maybe just look at the Wayland changes.

I have essentially implemented some of this for Windows in my pump_events branch, because I found it overly convoluted to try and maintain the old logic that was buffering redraw requests to be dispatched after MainEventsCleared.

I think it could also be good to add the present_notification API via a completely separate PR.

Conceptually I would see the present_notification API as way for Winit to get feedback about when the application renders which might be useful for a variety of use cases but in the short term it happens it provides a solution for letting the Wayland backend use frame callbacks.

So it's only indirectly related to throttling - it's needed for throttling on Wayland because otherwise it can't use frame callbacks but that feels like an implementation detail for the Wayland backend.

The stubbed macos change here also e.g. doesn't consider that setNeedsDisplayInRect can only be called from the main thread I'm fairly sure, so there still needs to be a queuing mechanism that goes via the main thread that could potentially call setNeedsDisplayInRect.

[kchibisov]

I think it could also be good to add the present_notification API via a completely separate PR.

I'll do 2 commits in this PR, because otherwise we'll add an API without a real use.

The stubbed macos change here also e.g. doesn't consider that setNeedsDisplayInRect can only be called from the main thread I'm fairly sure, so there still needs to be a queuing mechanism that goes via the main thread that could potentially call setNeedsDisplayInRect.

I just tested whether they work at all, but they don't, I'll revert them all together, because CVDisplayLink should be used.

I think I'll focus mostly on docs in this PR.

[rib]

I think it could also be good to add the present_notification API via a completely separate PR.

I'll do 2 commits in this PR, because otherwise we'll add an API without a real use.

yeah, makes sense

I think I'll focus mostly on docs in this PR.

Just to note that I at least made some updates to docs in the pump_events branch.

Maybe you could base on top of my pump_events branch to avoid conflicts?

[kchibisov]

Maybe you could base on top of my pump_events branch to avoid conflicts?

I've added just some basic docs, we could improve them with your work ofc, they shouldn't overlap from what I could say.

[kchibisov]

This is ready for review wrt docs.

@daxpedda if you want to send requestAnimationFrame you could do it after that patch, should be simply with your previous patch.

[rib]

I think it would be best to rename on_present_notify to something like pre_present_notify because it's important to be very clear that that this callback needs to happen before the application actually presents.

Just going by the name I think I would expect to call on_present_notify after presenting.

Especially for the initial Wayland use case where the backend wants an opportunity to insert a frame callback before the surface.commit() - this ordering is important.

[kchibisov]

I've renamed the method. @rib is this good for now?

[daxpedda]

Web backend implemented and approved.
Small question about the documentation.

[kchibisov]

@daxpedda could you recheck that I've rebased correctly web?

[rib]

One thing I was wanted to double check here @kchibisov is whether you have tested how apps behave if they omit the pre_present_notify call.

It would be good to be clear on whether this is now a hard requirement or whether the backend can reliably only enable throttling once it has seen that the application has called pre_present_notify at least once.

[kchibisov]

It would be good to be clear on whether this is now a hard requirement or whether the backend can reliably only enable throttling once it has seen that the application has called pre_present_notify at least once.

They will get instant redraw, so sounds fine to me, that's what they get before.

[daxpedda]

Web is fine, thanks @kchibisov.