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

Busy loop with clients requesting frame callbacks without rendering #2051

Closed
emersion opened this issue Mar 5, 2020 · 3 comments · Fixed by #2053
Closed

Busy loop with clients requesting frame callbacks without rendering #2051

emersion opened this issue Mar 5, 2020 · 3 comments · Fixed by #2053
Labels

Comments

@emersion
Copy link
Member

emersion commented Mar 5, 2020

Because of #2046 clients requesting frame callbacks without rendering at all cause a busy-loop in the compositor:

  1. Client requests frame callback without rendering anything
  2. Compositor resumes the rendering loop immediately
  3. Compositor notices nothing changed on screen, skips the page-flip
  4. Compositor sends frame callback event to client
  5. Goto (1)

This can be reproduced with the so-called "last good mpv commit" 8a83430a:

mpv --force-window --vid=1 --external-file=<path to image> <path to audio file>

Firefox also uses this behavior.

I'm putting together a test client right now.

@emersion emersion added the bug label Mar 5, 2020
@ascent12
Copy link
Member

ascent12 commented Mar 5, 2020

I think we should just make compositors always perform wlr_output_commit every frame, even if it contains no state changes or new rendering. i.e. wlr_output_commit is the thing that will trigger the frame callback to happen.

@emersion
Copy link
Member Author

emersion commented Mar 5, 2020

No, this would keep the rendering loop active even if nothing is happening (no visible clients requesting the frame callback).

@emersion
Copy link
Member Author

emersion commented Mar 5, 2020

emersion added a commit to emersion/wlroots that referenced this issue Mar 5, 2020
This way, wlr_output_schedule_frame will always be followed by a
wlr_output_commit. This forces the compositor to render an extra
frame before stopping the rendering loop.

To test, run wleird's frame-callback [1], make sure it's the only
visible client on the output and check the interval between frame
events is the output's refresh period instead of zero.

[1]: https://github.com/emersion/wleird/blob/master/frame-callback.c

Closes: swaywm#2051
emersion added a commit to emersion/wlroots that referenced this issue Mar 5, 2020
This way, wlr_output_schedule_frame will always be followed by a
wlr_output_commit. This forces the compositor to render an extra
frame before stopping the rendering loop.

To test, run wleird's frame-callback [1], make sure it's the only
visible client on the output and check the interval between frame
events is the output's refresh period instead of zero.

[1]: https://github.com/emersion/wleird/blob/master/frame-callback.c

Closes: swaywm#2051
ddevault pushed a commit that referenced this issue Mar 6, 2020
This way, wlr_output_schedule_frame will always be followed by a
wlr_output_commit. This forces the compositor to render an extra
frame before stopping the rendering loop.

To test, run wleird's frame-callback [1], make sure it's the only
visible client on the output and check the interval between frame
events is the output's refresh period instead of zero.

[1]: https://github.com/emersion/wleird/blob/master/frame-callback.c

Closes: #2051
filips pushed a commit to filips/wlroots that referenced this issue Mar 15, 2020
This way, wlr_output_schedule_frame will always be followed by a
wlr_output_commit. This forces the compositor to render an extra
frame before stopping the rendering loop.

To test, run wleird's frame-callback [1], make sure it's the only
visible client on the output and check the interval between frame
events is the output's refresh period instead of zero.

[1]: https://github.com/emersion/wleird/blob/master/frame-callback.c

Closes: swaywm#2051
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Development

Successfully merging a pull request may close this issue.

2 participants