winit: Add support for timer based frame throttling #8828
Conversation
|
This PR also positively fixes an issue that @DataTriny and I noticed that when trying to use the accessibility inspector on macOS with the gallery example, it's practically not responding to accessibility requests, unless the progress notification is turned off. With this patch the stays responsive towards the inspector even when the progress animation keeps running. |
internal/backends/winit/lib.rs
Outdated
| @@ -469,6 +470,8 @@ pub(crate) struct SharedBackendData { | |||
| clipboard: std::cell::RefCell<clipboard::ClipboardPair>, | |||
| not_running_event_loop: RefCell<Option<winit::event_loop::EventLoop<SlintEvent>>>, | |||
| event_loop_proxy: winit::event_loop::EventLoopProxy<SlintEvent>, | |||
| frame_throttle_factory: | |||
There was a problem hiding this comment.
Why go through the hoops of making a factory, while you could just call crate::frame_throttle::create_frame_throttle(self_weak.clone())) (notice the missing _factory) and have the #[cfg] logic in there.
There was a problem hiding this comment.
That was my original attempt, but the decision which type of throttle to pick is hard to make at this point :-(
Basically, I need to know if we're using wayland as windowing system, which is a run-time decision.
If I'm guaranteed to have a winit window, I can ask the window handle, check if it's wayland one, and it's all good. Unfortunately we don't have the winit window at adapter creation time. We may not even have it yet by the time WindowAdapter::request_redraw() is called (as user code can call it). So the winit window's lack of reliable availability is a problem.
The next entity is the event loop, for which there are (right now) two variants, the not running event loop (winit::event_loop::EventLoop) and the &ActiveEventLoop. If I can get hold of either of those two, I can use EventLoopExtWayland or ActiveEventLoopExtWayland. Unfortunately, the winit::event_loop::EventLoop is only available before spinning the event loop. Once it spins, it's consumed by winit and we only have the &ActiveEventLoop from within callbacks of the ApplicationHandler trait. So from those we could also get it, but then ... request_redraw() is a function that can be called from user code and the &ActiveEventLoop is nowhere nearby.
I could resurrect the scoped_tls_hkt::scoped_thread_local!(pub(crate) static ACTIVE_EVENT_LOOP : for<'a> &'a ActiveEventLoop);, but I'm actually really happy that we got rid of it ;-).
Hence my preference to this indirection and the decision being made at the earliest possible time, when we still have the not running EventLoop.
There was a problem hiding this comment.
Maybe could store is_wayland in SharedBackendData ?
There was a problem hiding this comment.
Hehe, yes, I tried that but didn't like the cfg'ery around it so much. But let me try again, now that went to the other extreme :).
…ndow adapter constructor
Fixes #8826