Compositing is triggered continously and needlessly when there are occluded surfaces with available buffers
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Fix Released
|
High
|
Daniel van Vugt | ||
mir (Ubuntu) |
Fix Released
|
High
|
Unassigned |
Bug Description
Because of recent changes in the way the MultiThreadedCo
To test this, run the proving server:
$ sudo bin/mir_
then start a client and drag the client offscreen. The compositor log should report that the compositor has a frame rate of max(client frame, FDP) (FDP=value related to our frame droping policy). However, you will see that it's instead rendering at 60FPS.
As an extreme (but not unusual) example of how problematic this behavior can be, perform the following:
1. Change an example client to render at ~1 FPS (e.g. add sleep(1) in it's main loop).
2. Perform the previous experiment with that client
When the client surface is visible, the compositor is triggered at a rate of 1FPS. The same should be true when the surface is dragged off screen, but instead we get a full compositing rate of 60FPS.
[1] https:/
Related branches
- PS Jenkins bot (community): Approve (continuous-integration)
- Robert Carr (community): Needs Information
- Kevin DuBois (community): Approve
- Alan Griffiths: Approve
-
Diff: 62 lines (+33/-1)2 files modifiedsrc/server/scene/surface_stack.cpp (+5/-1)
tests/unit-tests/scene/test_surface_stack.cpp (+28/-0)
summary: |
Compositing is triggered continously and needlessly when there are - occluded surfaces + occluded surfaces with available buffers |
Changed in mir: | |
importance: | Medium → High |
milestone: | none → 0.11.0 |
status: | New → In Progress |
milestone: | 0.11.0 → 0.12.0 |
Changed in mir: | |
milestone: | 0.12.0 → 0.13.0 |
no longer affects: | mir/0.11 |
Changed in mir (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in mir: | |
status: | Fix Committed → Fix Released |
Unfortunately this sounds kind of right.
We failed to consume all buffers last frame, and it's quite possible that the shell has changed something that allows them to be consumed on the next. So the right answer is indeed to schedule a frame immediately.
To solve this for everyone we would probably have to distinguish between the _reasons_ for a buffer not getting consumed. Starts to sound messy.