| 2014-11-02 02:37:47 |
Daniel van Vugt |
bug |
|
|
added bug |
| 2014-11-02 02:38:06 |
Daniel van Vugt |
description |
Running a server and a few clients on an Atom N270 is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering becomes perfectly smooth ~60 FPS.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
Running a server and a few clients on an Atom N270 (requires vivid) is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering becomes perfectly smooth ~60 FPS.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
|
| 2014-11-02 02:41:18 |
Daniel van Vugt |
tags |
|
performance |
|
| 2014-11-02 04:09:53 |
Daniel van Vugt |
mir: assignee |
Daniel van Vugt (vanvugt) |
|
|
| 2014-11-03 00:28:44 |
Daniel van Vugt |
description |
Running a server and a few clients on an Atom N270 (requires vivid) is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering becomes perfectly smooth ~60 FPS.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
Running a server and a few clients on an Atom N270 (requires vivid) is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering (of everything) becomes perfectly smooth ~60 FPS.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
|
| 2014-11-04 14:31:12 |
Cemil Azizoglu |
mir: assignee |
|
Cemil Azizoglu (cemil-azizoglu) |
|
| 2014-11-09 07:17:36 |
Lime |
bug |
|
|
added subscriber Lime |
| 2014-11-18 23:33:32 |
Alberto Aguirre |
mir: milestone |
0.9.0 |
0.10.0 |
|
| 2014-12-03 21:49:51 |
Cemil Azizoglu |
mir: assignee |
Cemil Azizoglu (cemil-azizoglu) |
|
|
| 2014-12-24 10:54:30 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/mir/wakelocks |
|
| 2014-12-24 10:54:45 |
Daniel van Vugt |
branch linked |
|
lp:~thomas-voss/mir/reenable-wakelock-acquisition-in-input-stack |
|
| 2014-12-24 10:54:56 |
Daniel van Vugt |
branch unlinked |
lp:~thomas-voss/mir/reenable-wakelock-acquisition-in-input-stack |
|
|
| 2014-12-28 14:18:39 |
Daniel van Vugt |
mir: milestone |
0.10.0 |
|
|
| 2014-12-28 14:19:16 |
Daniel van Vugt |
summary |
Frame rate is artificially low on some systems |
Frame rate is artificially low on some systems due to Intel C-States |
|
| 2014-12-28 14:19:21 |
Daniel van Vugt |
mir: importance |
High |
Medium |
|
| 2015-03-03 08:56:51 |
Daniel van Vugt |
description |
Running a server and a few clients on an Atom N270 (requires vivid) is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering (of everything) becomes perfectly smooth ~60 FPS.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
Running a server and a few clients on an Atom N270 (requires vivid) is very stuttery and apparently limited to around 20 FPS.
However this limitation is a bug. Firstly I notice the system is still 70% idle according to top. And if I drag the mouse constantly over a surface or move a window constantly, the rendering (of everything) becomes perfectly smooth ~60 FPS. Also using --compositor-report=log on the Mir server shows the compositor render time even on this very weak machine is only 2.6ms.
So we have a scheduling problem and forcing re-compositing via input is working around it. Obviously the clients themselves are not able to wake up the compositor frequently enough to ensure new frames get scheduled. However if I wake up the compositor using demo-shell mouse gestures then all is fast and smooth.
This seems to be the same kind of scheduling problem also observed on higher-end systems when the compositor buffer pipeline is reduced --> bug 1377872 |
|
| 2015-03-25 03:07:08 |
Daniel van Vugt |
summary |
Frame rate is artificially low on some systems due to Intel C-States |
Frame rate is artificially low on older Intel Atom systems due to aggressive power management |
|
| 2016-05-19 09:39:44 |
Daniel van Vugt |
summary |
Frame rate is artificially low on older Intel Atom systems due to aggressive power management |
Frame rate is artificially low on Diamondville Intel Atom systems due to aggressive power management |
|
| 2017-01-15 12:08:29 |
Daniel van Vugt |
mir: assignee |
|
Daniel van Vugt (vanvugt) |
|
| 2017-01-15 12:08:33 |
Daniel van Vugt |
mir: milestone |
|
1.0.0 |
|
| 2017-01-15 12:08:36 |
Daniel van Vugt |
mir: status |
Triaged |
In Progress |
|
| 2017-01-15 12:08:48 |
Daniel van Vugt |
branch linked |
|
lp:~vanvugt/mir/client-side-vsync |
|
| 2017-01-17 18:52:53 |
Mir CI Bot |
mir: status |
In Progress |
Fix Committed |
|
| 2017-01-20 02:10:01 |
Daniel van Vugt |
mir: milestone |
1.0.0 |
0.26.0 |
|
| 2017-01-25 06:46:40 |
Daniel van Vugt |
bug task added |
|
mir (Ubuntu) |
|
| 2017-01-25 17:22:22 |
Launchpad Janitor |
branch linked |
|
lp:~ci-train-bot/mir/mir-ubuntu-zesty-2369 |
|
| 2017-01-30 09:24:36 |
Daniel van Vugt |
tags |
performance |
atom performance |
|
| 2017-02-01 22:13:22 |
Launchpad Janitor |
mir (Ubuntu): status |
New |
Fix Released |
|
| 2017-02-02 03:22:00 |
Daniel van Vugt |
mir: status |
Fix Committed |
Fix Released |
|
| 2017-06-05 11:01:50 |
Launchpad Janitor |
branch linked |
|
lp:~ci-train-bot/mir/mir-ubuntu-xenial-2736 |
|
| 2017-06-05 11:02:25 |
Launchpad Janitor |
branch linked |
|
lp:~ci-train-bot/mir/mir-ubuntu-yakkety-2783.1 |
|
| 2017-06-05 13:46:31 |
Launchpad Janitor |
branch linked |
|
lp:~ci-train-bot/mir/mir-ubuntu-yakkety-2783 |
|
