Merge lp://staging/~mterry/ubuntu-touch-session/usc into lp://staging/ubuntu-touch-session

Switch Touch images to use unity-system-compositor.

Switch Touch images to use unity-system-compositor.

This is useful because:
- it is one step closer to a proper user set up (allows for multiple user unity8 sessions, allows root to manage the graphics hardware instead of the phablet user)
- it brings Touch images closer to how Desktop images will look with Mir

There is a definite possibility of performance impact. There are some benchmark results at the bottom to show the effect of enabling USC.

= Testing =

When testing, please try with both surfaceflinger enabled or disabled, to make sure that fallback works fine.

Otherwise, you shouldn't really notice a change, except that unity-system-compositor will be running in normal Mir mode.

= Benchmark tl;dr; =

We're fine. No noticable performance hit from USC and nested mode.

== Startup Time ==

Since we are now starting USC before unity8 and then running unity8 in a nested mode, it seemed very likely that there would be a performance hit on startup. To test this, I took a timestamp right before starting lightdm and right as the greeter finished showing to the user (I had to modify code to get this one).

Using current standalone mode:
Startup times: 52 12 14 13 12 64 98 106 13 98 24 23 13
Mean: 41.69

With USC and nested mode:
Startup times: 53 13 66 12 13 58 64 53 64 105 13 13 65
Mean: 45.54

Seems like startup hits two possible code paths: a short and a long one (and arguably a super long one). This doesn't seem related to my branch. I suspect it's apport?

I provided a mean for before my branch and after, which shows that there is a slight hit with USC. But in truth, I think the additional time is just that I just happened to hit more of the long code paths during the USC run. If you look at individal scores, I think we're fine.

== Running Time ==

Here are results of timed autopilot runs. Methodology is using 'time' to measure the length, and averaging three runs, rounded to the second.

unity8 standalone: 562s
unity8 nested: 536s

gallery_app standalone: 453s
gallery_app nested: 445s

mediaplayer_app standalone: 21s
mediaplayer_app nested: 23s

camera_app standalone: 51s
camera_app nested: 50s

So, all in all, slightly better or about the same.

=== QML_RENDER_TIMING=1 ===

I've also set QML_RENDER_TIMING=1 for unity8 in both nested and standalone modes. This enables printing of frame timings. Nested is roughly equivalent to standalone. A little higher for nested, but nothing large. ricmm and greyback both said it was fine.

(I don't have results on me, and they'd be hard to summarize anyway.)

== Battery Drain ==

It also seems reasonable that battery might drain more. USC could in theory be holding more memory or doing something dumb like busy waiting.

Colin King is strongly of the opinion that we need specialized equipment to get proper battery detection [1]. And he's right. But I used "upower -d" to get quick and dirty calculations, on the theory that at least I could see if USC was taking A LOT of power.

[1] http://smackerelofopinion.blogspot.co.uk/2012/11/non-linear-characteristics-in-draining.html

Here's my methodology: Start with 100% charge phone. Make sure screen is forced bright by powerd (so we don't suspend). Disconnect from computer and let sit for an hour. Check battery with upower -d.

Using current standalone mode: Went from 9.17399 Wh to 8.52732 Wh in 56 minutes.
Drain rate: 0.011547679 Wh/min

With USC and nested mode: Went from 9.17399 Wh to 8.4499 Wh in 62 minutes.
Drain rate: 0.011678871 Wh/min

I think that's negligible, especially considering the method. Almost certainly within margin of error.