[regression] MultiThreadedCompositor fails to schedule sufficient frames and may lag at random times
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Incomplete
|
High
|
Daniel van Vugt | ||
mir (Ubuntu) |
Incomplete
|
High
|
Unassigned | ||
mir (Ubuntu RTM) |
Incomplete
|
High
|
Unassigned |
Bug Description
MultiThreadedCo
1. surfaceA emits a frame, one is scheduled
2. surfaceA emits another frame, but still only one is scheduled for compositing
3. We composite only one frame (frames_scheduled == 1)
4. System is idle for some unknown time, with no compositing scheduled but surfaceA has its 2nd frame rendered that we're not seeing.
The problem is:
void schedule_
{
if (num_frames > frames_scheduled)
{
}
}
If a surface only emits schedule_
If correct, this would explain bug 1295851 but I will keep them separate while we're not 100% sure.
Related branches
description: | updated |
summary: |
- MultiThreadedCompositor fails to schedule sufficient frames + MultiThreadedCompositor fails to schedule sufficient frames and may lag + at random times |
Changed in mir (Ubuntu RTM): | |
importance: | Undecided → High |
status: | New → Triaged |
Changed in mir (Ubuntu): | |
importance: | Undecided → High |
status: | New → Triaged |
no longer affects: | mir/0.7 |
no longer affects: | mir/0.8 |
I know for a fact that MultiThreadedCo mpositor has employed a few different algorithms over the past year or so. And most of them are immune to this problem. So this is a relatively recent (past ~6 months) regression. Can't quite find which revision introduced the regression.