Widget-driven animations

[hecrj]

Fixes #31 and closes #560.

This PR introduces a new method request_redraw to the Shell type which enables a Widget to request a redraw during on_event.

Shell::request_redraw takes a window::RedrawRequest, which is defined as follows:

/// A request to redraw a window.
#[derive(Debug, Clone, Copy, PartialEq, Eq, PartialOrd, Ord)]
pub enum RedrawRequest {
    /// Redraw the next frame.
    NextFrame,

    /// Redraw at the given time.
    At(Instant),
}

Additionally, a new variant RedrawRequested(Instant) has been added to window::Event. This event is triggered before the user interface is redrawn.

As a result, widgets can now choose to draw whenever necessary; making animations possible! For instance, the TextInput widget has now a blinking cursor:

2023-01-11.05-36-44.mp4

Furthermore, these changes allow us to finally implement a subscription to subscribe to the frame rate of a window. The brand new window::frames subscription produces an Instant at the same frequency as the frame rate of the screen of the user. This can be very useful to smoothly animate layout or different parts of an application (as opposed to using time::every with a fixed frame rate). The solar_system example now uses the window::frames subscription!

[ids1024]

I guess this currently depends on GL swap_buffers or wgpu present blocking until vsync? (With an appropriate swap interval or present mode.) I guess that's the right way to do it until rust-windowing/winit#2412 is implemented.

On Wayland, Mesa's EGL/WSI implementation uses wl_surface::frame here, which may block indefinitely for occluded windows (does this block other parts of Iced in an undesirable way?). So it should be noted that the event won't necessarily be emitted regularly. I'm not sure exactly what the behavior is like on other platforms.

[13r0ck]

Furthermore, these changes allow us to finally implement a subscription to subscribe to the frame rate of a window.

That is very exciting

[hecrj]

I guess this currently depends on GL swap_buffers or wgpu present blocking until vsync? (With an appropriate swap interval or present mode.) I guess that's the right way to do it until rust-windowing/winit#2412 is implemented.

Yes. Without vsync, the RedrawRequested event will be produced as fast as possible when subscribed to window::frames. Since redraws are graphical, it seems appropriate to let the graphics driver control the framerate (instead of trying to figure out the screen frame rate and throttle ourselves).

On Wayland, Mesa's EGL/WSI implementation uses wl_surface::frame here, which may block indefinitely for occluded windows (does this block other parts of Iced in an undesirable way?). So it should be noted that the event won't necessarily be emitted regularly. I'm not sure exactly what the behavior is like on other platforms.

I can clarify in the docs that the subscription matches the maximum refresh rate of the window at any given moment, which is in turn controlled by graphics drivers and the OS.

In any case, there is no reason to believe the event will be emitted regularly even with the current docs, since a window can be moved to a screen with different refresh rate. This is why an Instant is provided for delta calculations in the RedrawRequested event.