Merge lp:~mterry/unity-system-compositor/default-wallpaper into lp:unity-system-compositor
| Status: | Merged |
|---|---|
| Approved by: | Michael Terry on 2016-09-02 |
| Approved revision: | 300 |
| Merged at revision: | 300 |
| Proposed branch: | lp:~mterry/unity-system-compositor/default-wallpaper |
| Merge into: | lp:unity-system-compositor |
| Diff against target: |
178 lines (+40/-15) 4 files modified
CMakeLists.txt (+1/-0) debian/control (+2/-0) spinner/CMakeLists.txt (+2/-7) spinner/eglspinner.cpp (+35/-8) |
| To merge this branch: | bzr merge lp:~mterry/unity-system-compositor/default-wallpaper |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Mir CI Bot | continuous-integration | Approve on 2016-09-02 | |
| Alexandros Frantzis (community) | 2016-06-17 | Approve on 2016-08-25 | |
|
Review via email:
|
|||
Commit Message
Use system wallpaper instead of custom built-in one.
Additionally, crop it instead of stretching it.
Description of the Change
I used gdk-pixbuf for loading the image. Is there a better library to use? We were already using glib, so it didn't seem like a big stretch.
Question for reviewers: how badly do we want performance here? It's good to reduce the gap between the firmware screen and the spinner screen. Here's rough timings from program launch to first frame for the old background and new (on my laptop, which is presumably beefier than my phone):
Old background (statically linked into binary): ~0.080s
New background (statically linked into binary): ~0.125s
New background (dynamically loaded): ~0.250s
This MP is currently dynamically loaded, since it's "most correct". But it might be worth statically linking the image for the time savings? It means we'd have to no-change rebuild the package every time ubuntu-wallpapers updates the default image before USC picks it up.
I'm open to options.
Also related:
- https:/
- https:/
I've made silo 23 that includes all three for easier testing.
| Michael Terry (mterry) wrote : | # |
/me looks into the startup timing changes involved in loading the image dynamically vs built in.
| Michael Terry (mterry) wrote : | # |
OK, added some brief timing notes in the description.
| Alexandros Frantzis (afrantzis) wrote : | # |
Code looks good.
On krillin the timings I get are:
static wallpaper.png 0.34s
dynamic wallpaper.png 0.28s !!!
static warty-final-
dynamic warty-final-
For the large background, the penalty for dynamically loading is 0.2s, whereas there seems to be a slight benefit for the small background.
Note that dynamically loading presents a net gain in installed size, which may be a concern on the phone. With static embedding unity-system-
Ideas for improved performance:
* Also provide a lower resolution (e.g. 1920x1080) version of the default background. If the display is not larger than that we could just go with the small version and improve performance a lot.
* We could experiment with using libpng directly to check if it reduces loading time.
My vote is to go with dynamic loading, since it's the lowest maintenance solution (no need for rebuilds etc), and the runtime cost is not prohibitive, especially if we implement idea (1) and provide a lower resolution image also.
| Alexandros Frantzis (afrantzis) wrote : | # |
Actually small concern/needs info:
On krillin I see a horizontal line just behind the logo, as if like the image somehow restarts at that point. Could this be a cropping artifact?
| Michael Terry (mterry) wrote : | # |
You mentioned the size of installing ubuntu-wallpapers. We need ubuntu-wallpapers for the other components of this change (ubuntu-
And I agree it's annoying that ubuntu-wallpapers assumes you want all of vivid-wallpapers too.
I'll test on krillin and see about that horizontal line...
| Michael Terry (mterry) wrote : | # |
Ah that horizontal line is actually part of the wallpaper. See http://
| Mir CI Bot (mir-ci-bot) wrote : | # |
FAILED: Autolanding.
More details in the following jenkins job:
https:/
Executed test runs:
FAILURE: https:/
None: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/

FAILED: Continuous integration, rev:300 /mir-jenkins. ubuntu. com/job/ usc-ci/ 30/ /mir-jenkins. ubuntu. com/job/ build-usc/ 41/console /mir-jenkins. ubuntu. com/job/ build-0- fetch/1364 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= vivid+overlay/ 1355 /mir-jenkins. ubuntu. com/job/ build-1- sourcepkg/ release= xenial/ 1355 /mir-jenkins. ubuntu. com/job/ build-2- binpkg- usc/arch= amd64,release= xenial/ 45/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- usc/arch= armhf,release= vivid+overlay/ 45/console /mir-jenkins. ubuntu. com/job/ build-2- binpkg- usc/arch= i386,release= xenial/ 45/console
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
SUCCESS: https:/
SUCCESS: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild: /mir-jenkins. ubuntu. com/job/ usc-ci/ 30/rebuild
https:/