Mir

Merge lp://staging/~vanvugt/mir/flush into lp://staging/mir

flush
Merge into development-branch

Proposed by Daniel van Vugt on 2014-08-12

Status:

Work in progress

Proposed branch:

lp://staging/~vanvugt/mir/flush

Merge into:

lp://staging/mir

Diff against target:

295 lines (+174/-10)

3 files modified

src/server/compositor/multi_threaded_compositor.cpp (+52/-8)
src/server/compositor/multi_threaded_compositor.h (+8/-2)
tests/unit-tests/compositor/test_multi_threaded_compositor.cpp (+114/-0)

To merge this branch:

bzr merge lp://staging/~vanvugt/mir/flush

Medium

Opinion

Link a bug report

Reviewer	Review Type	Date Requested	Status
PS Jenkins bot (community)	continuous-integration		Approve on 2014-09-09
Alberto Aguirre (community)			Needs Information on 2014-08-28
Alexandros Frantzis (community)			Needs Information on 2014-08-12
Kevin DuBois (community)		2014-08-12	Needs Fixing on 2014-08-12
Review via email: mp+230436@code.staging.launchpad.net

Commit message

When restarting the compositor (including waking from sleep), flush
the scene and wait briefly for fresh frames. Then composite as soon as the
client (nested server) provides a new frame or the timeout of 500ms expires,
whichever happens first. This avoids the user seeing any stale frames on
wakeup.

This feature will also be useful in future as clients adjust to
display config changes seamlessly without visibly lagging behind the new
config (like resolution changes when a window is maximized).

Description of the change

This branch was intended to help with LP: #1340510. Although it's now clear that bug is more to do with Unity8/dbus and less to do with Mir. So this improvement to Mir isn't expected to solve LP: #1340510 by itself.

Still, this proposal is useful to have for other potential shells that respond to wakeup more quickly than Unity8 does right now.

Revision history for this message

Kevin DuBois (kdub) wrote on 2014-08-12:

needs fixing:

166 + void schedule_compositing(int number_composites,
167 + std::chrono::milliseconds delay = std::chrono::milliseconds::zero());

default arguments ( http://unity.ubuntu.com/mir/cppguide/index.html?showone=Default_Arguments#Default_Arguments )

suggestion:
The solution isn't bad, but alternatively, we could have the objects implementing mir::DisplayChanger/mf::DisplayChanger trigger a display composition on wakeup. This could avoid messing with the timeouts.

review: Needs Fixing

Revision history for this message

Alexandros Frantzis (afrantzis) wrote on 2014-08-12:

Note that we already have support for dropping older frames when a surface becomes visible (restarting a compositor is a special case of this). The frame dropping supported was added by https://code.launchpad.net/~afrantzis/mir/drop-stale-frames/+merge/227961 as a partial fix for the same bug targetted by this MP.

The existing mechanism ensures that we use the latest client frame instead of rapidly showing stale queued frames. This MP is slightly different in that it tries to force the clients to redraw, then waits for some amount of time hoping that they have produced a newer frame. However, for the time intervals we are using ( > 100ms which is larger than our BufferQueues's framedropping policy timeout), I don't think forcing new frames will make much difference, and I am not sure if the complexity is worth it.

As you note, the real problem is the slow greeter rendering.

review: Needs Information

Revision history for this message

Alexandros Frantzis (afrantzis) wrote on 2014-08-12:

> This MP is slightly different in that it

Well not slightly different, rather just "different".

Revision history for this message

PS Jenkins bot (ps-jenkins) wrote on 2014-08-12:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/2367/rebuild

review: Approve (continuous-integration)

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-08-13:

Yeah, I'm undecided about this branch now. The complexity is a bit ugly. I had a simpler version prepared but intentionally didn't propose it thinking more people would prefer this one.

Anyway, now my ABI problems are apparently resolved today I will do some system testing on the phone.

Revision history for this message

Alberto Aguirre (albaguirre) wrote on 2014-08-28:

Yeah I though this was already handled by the update to BufferQueue from Alexandros.

Do we need more than that?

review: Needs Information

Revision history for this message

Daniel van Vugt (vanvugt) wrote on 2014-08-29:

It's a handy feature. And it is still required (after Unity8 gets fixed) to fully resolve bug 1340510, based on my own experiments inserting delays into clients. Not sure why Alexandros' existing code wasn't enough...? But either way, this solution scales better than putting too much intelligence in BufferQueue (which is instantiated for every surface).

So yes, I think we will still need something like this. But it's not needed right now.

lp://staging/~vanvugt/mir/flush updated on 2014-09-09

1843. By Daniel van Vugt on 2014-08-13: Merge latest development-branch
1844. By Daniel van Vugt on 2014-08-14: Merge latest development-branch
1845. By Daniel van Vugt on 2014-08-15: Merge latest development-branch
1846. By Daniel van Vugt on 2014-08-18: Merge latest development-branch
1847. By Daniel van Vugt on 2014-08-19: Merge latest development-branch
1848. By Daniel van Vugt on 2014-08-22: Merge latest development-branch
1849. By Daniel van Vugt on 2014-08-25: Merge latest development-branch
1850. By Daniel van Vugt on 2014-08-28: Merge latest development-branch
1851. By Daniel van Vugt on 2014-08-28: Merge latest development-branch
1852. By Daniel van Vugt on 2014-08-29: Merge latest development-branch
1853. By Daniel van Vugt on 2014-09-01: Merge latest development-branch
1854. By Daniel van Vugt on 2014-09-02: Merge latest development-branch
1855. By Daniel van Vugt on 2014-09-03: Merge latest development-branch
1856. By Daniel van Vugt on 2014-09-03: Merge latest development-branch
1857. By Daniel van Vugt on 2014-09-04: Merge latest development-branch
1858. By Daniel van Vugt on 2014-09-05: Merge latest development-branch
1859. By Daniel van Vugt on 2014-09-08: Merge latest development-branch
1860. By Daniel van Vugt on 2014-09-09: Merge latest development-branch and fix conflicts

Revision history for this message

PS Jenkins bot (ps-jenkins) wrote on 2014-09-09:

PASSED: Continuous integration, rev:1860
http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-ci/2657/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-utopic-i386-build/1665
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-utopic-amd64-build/1671
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-utopic-touch/1647
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/1179
        deb: http://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-utopic-amd64-ci/1179/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/584
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-utopic-armhf/584/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/2704
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/12928

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-ci/2657/rebuild

review: Approve (continuous-integration)

Unmerged revisions

1860. By Daniel van Vugt on 2014-09-09: Merge latest development-branch and fix conflicts
1859. By Daniel van Vugt on 2014-09-08: Merge latest development-branch
1858. By Daniel van Vugt on 2014-09-05: Merge latest development-branch
1857. By Daniel van Vugt on 2014-09-04: Merge latest development-branch
1856. By Daniel van Vugt on 2014-09-03: Merge latest development-branch
1855. By Daniel van Vugt on 2014-09-03: Merge latest development-branch
1854. By Daniel van Vugt on 2014-09-02: Merge latest development-branch
1853. By Daniel van Vugt on 2014-09-01: Merge latest development-branch
1852. By Daniel van Vugt on 2014-08-29: Merge latest development-branch
1851. By Daniel van Vugt on 2014-08-28: Merge latest development-branch