[performance] Rendering is only smooth while you're touching the screen
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mir |
Incomplete
|
Undecided
|
Daniel van Vugt | ||
Unity System Compositor |
In Progress
|
Undecided
|
Thomas Voß | ||
mir (Ubuntu) |
Incomplete
|
Undecided
|
Unassigned | ||
qtmir (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
On some devices (mako at least) it's possible to force double buffering and it will often keep up:
restart unity8 QML_NO_
Curiously however it only keeps up smoothly (eg. during a dash scroll) while you're touching the screen. If you lift off or fling the dash then it immediately stutters, quite badly.
So the issue is not that the device can't keep up with double buffering. It seems more like we're not keeping the kernel sufficiently awake and it's clocking down prematurely, as soon as we're not touching it. Certainly adjusting the variables in:
/sys/
it is possible to raise the performance and minimum frequency to make double buffering smooth.
The challenge of this bug is to find a way in Mir/QtMir to keep the kernel more awake so it doesn't clock down when we need smooth animations and we're not touching the screen.
Also note that while this bug sounds like bad news for mako, mako is actually the best performing device. Others like arale don't reliably speed up in response to short touches.
summary: |
- Double buffering is only smooth while you're touching it + [performance] Double buffering is only smooth while you're touching it |
Changed in mir: | |
assignee: | Daniel van Vugt (vanvugt) → Thomas Voß (thomas-voss) |
description: | updated |
Changed in unity-system-compositor: | |
assignee: | nobody → Thomas Voß (thomas-voss) |
status: | New → In Progress |
summary: |
- [performance] Double buffering is only smooth while you're touching it + [performance] Rendering is only smooth while you're touching the screen |
no longer affects: | qtmir |
Could be a simple matter of increasing our concurrency. If that's not kept high enough then the delay between context switches likely becomes unacceptably high. And each frame requires at least 4 context switches (USC -> Unity8 -> app -> Unity8 -> USC).