Merge lp://staging/~vanvugt/mir/mesa-double into lp://staging/mir
Status: | Merged |
---|---|
Approved by: | Kevin DuBois |
Approved revision: | no longer in the source branch. |
Merged at revision: | 2218 |
Proposed branch: | lp://staging/~vanvugt/mir/mesa-double |
Merge into: | lp://staging/mir |
Diff against target: |
126 lines (+57/-8) 3 files modified
src/platforms/mesa/display_buffer.cpp (+25/-0) tests/unit-tests/graphics/mesa/test_display.cpp (+2/-1) tests/unit-tests/graphics/mesa/test_display_buffer.cpp (+30/-7) |
To merge this branch: | bzr merge lp://staging/~vanvugt/mir/mesa-double |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
PS Jenkins bot (community) | continuous-integration | Approve | |
Robert Carr (community) | Approve | ||
Alexandros Frantzis (community) | Approve | ||
Alan Griffiths | Approve | ||
Cemil Azizoglu | Pending | ||
Review via email: mp+245723@code.staging.launchpad.net |
Commit message
mesa::DisplayBu
instead of triple when it's safe to do so (not clone mode). This
noticeably reduces visible lag. (LP: #1350725)
Clone mode still needs triple buffering because you can't tell two or
more separate monitors to vblank at the same time. You just have to
accept that waiting for multiple vblanks will often take an extra
frame's time.
The more common cases of single or separate outputs however only need
to deal with one vsync signal per frame so can be optimized into
double buffering. And this feels significantly less laggy when dragging
windows around.
This is an improvement on the present behaviour introduced in r1380.
Description of the change
Q: What difference does one frame make?
A: A lot. It's the difference between the mouse pointer staying on your titlebar during window drags, and not.
Q: Is this really a priority?
A: Short term, no. But I've been sitting on this branch for almost two months and want to get it out the way. Longer term: Yes, less lag is important for Unity and everyone.
* Request for manual testing *
I'm satisfied performance is now good enough (since swap-then-flip) that we can afford to go back to a double buffered compositor. However beware of:
- Intel bug 1377872
- General performance bug 1395421
which could both be more noticeable as a result of this.
FAILED: Continuous integration, rev:2064 jenkins. qa.ubuntu. com/job/ mir-ci/ 2583/ jenkins. qa.ubuntu. com/job/ mir-android- vivid-i386- build/753 jenkins. qa.ubuntu. com/job/ mir-clang- vivid-amd64- build/753 jenkins. qa.ubuntu. com/job/ mir-mediumtests -vivid- touch/715 jenkins. qa.ubuntu. com/job/ mir-vivid- amd64-ci/ 580/console jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 715 jenkins. qa.ubuntu. com/job/ mir-mediumtests -builder- vivid-armhf/ 715/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ mir-mediumtests -runner- mako/3845 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 16864
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
FAILURE: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/mir- ci/2583/ rebuild
http://