Skip to content
This repository has been archived by the owner on Nov 1, 2021. It is now read-only.

output: remove wlr_output_impl.schedule_frame #2046

Merged
merged 1 commit into from
Mar 4, 2020

Conversation

emersion
Copy link
Member

@emersion emersion commented Mar 2, 2020

This function allowed backends to provide a custom function for frame
scheduling. Before resuming the rendering loop, the DRM and Wayland
backends would wait for vsync.

There isn't a clear benefit of doing this. The only upside is that we
get more stable timings: the delay between two repaints doesn't change too
much and is close to a mutliple of the refresh rate.

However this introduces latency, especially when a client misses a
frame. For instance a fullscreen game missing vblank will need to wait
more than a whole frame before being able to display new content. This
worst case scenario happens as follows:

  • Client is still rendering its frame and cannot submit it in time
  • Deadline is reached
  • Compositor decides to stop the rendering loop since nothing changed on
    screen
  • Client finally manages to render its frame, submits it
  • Compositor calls wlr_output_schedule_frame
  • DRM backend waits for next vblank
  • The wlr_output frame event is fired, compositor draws new content on screen
  • On the second next vblank, the new content reaches the screen

With this patch, the wlr_output frame event is fired immediately when
the client submits its late frame.

This change also makes it easier to support variable refresh rate, since
VRR is all about being able to present too-late frames earlier.

References: #1925

cc @ascent12 @YaLTeR


Breaking change: wlr_output_impl.schedule_frame has been removed.

This function allowed backends to provide a custom function for frame
scheduling. Before resuming the rendering loop, the DRM and Wayland
backends would wait for vsync.

There isn't a clear benefit of doing this. The only upside is that we
get more stable timings: the delay between two repaints doesn't change too
much and is close to a mutliple of the refresh rate.

However this introduces latency, especially when a client misses a
frame. For instance a fullscreen game missing vblank will need to wait
more than a whole frame before being able to display new content. This
worst case scenario happens as follows:

- Client is still rendering its frame and cannot submit it in time
- Deadline is reached
- Compositor decides to stop the rendering loop since nothing changed on
  screen
- Client finally manages to render its frame, submits it
- Compositor calls wlr_output_schedule_frame
- DRM backend waits for next vblank
- The wlr_output frame event is fired, compositor draws new content on screen
- On the second next vblank, the new content reaches the screen

With this patch, the wlr_output frame event is fired immediately when
the client submits its late frame.

This change also makes it easier to support variable refresh rate, since
VRR is all about being able to present too-late frames earlier.

References: swaywm#1925
@emersion emersion added the breaking Breaking change in public API label Mar 2, 2020
@emersion emersion mentioned this pull request Mar 2, 2020
2 tasks
Copy link
Contributor

@YaLTeR YaLTeR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I never quite wrapped my head around how this worked so I can't really give any feedback on the patch apart from that I'm glad that complexity is being reduced.

@ddevault
Copy link
Contributor

ddevault commented Mar 4, 2020

Thanks!

@ddevault ddevault merged commit 348f52b into swaywm:master Mar 4, 2020
@emersion emersion deleted the remove-backend-schedule-frame branch July 15, 2020 17:50
@emersion emersion added this to the 0.11.0 milestone Jul 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
breaking Breaking change in public API
Development

Successfully merging this pull request may close these issues.

None yet

3 participants