Rendering gets really slow with more than ~4 running (or well, suspended) apps

[Michael Zanetti]

Opening lots of apps has a quite big bad impact on the overall rendering performance of the phone. Starting with around 4 apps, first slowness is noticeable, increasing the number makes it become worse and worse. At the number of around 10 apps the phone is mostly unusable (bug 1267323)

Note, this is not some app hogging the CPU or anything, given that all the apps are suspended and CPU usage is at 0%. It seems like each app would add a major overhead to the rendering code in the display server.

Its nicely visible with the Launcher: With no apps the Launcher folding animation is smooth and nice. After opening the apps it gets quite bad.

Given that the right edge animation looks best with many apps in it, this is becoming a blocking issue for the work on the right edge animation.

[Michał Sawicz (saviq)]

I can confirm this, and it looks like a rendering issue, since both CPU is idle and RAM is free.

[Omer Akram (om26er)]

its probably bug 1227739‎

[Daniel van Vugt (vanvugt)]

Duplicate of bug 1267323.

[Daniel van Vugt (vanvugt)]

Unduplicating this bug to focus on the slow-with-4-clients issue. If you have 10 or more clients and they freeze, then that is bug 1267323.

[Daniel van Vugt (vanvugt)]

Regarding the slowness with 4 clients... You should first check that the clients are behaving well:
  (1) They use only opaque mir surfaces (no alpha channel in the pixel format);
  (2) They don't continue to use any CPU time when they're not visible (check for wakeups with a tool like powertop)

Regarding the 10+ apps making the system unusable... Please discuss that in bug 1267323.

[Michael Zanetti (mzanetti)]

please read the description again. The apps are suspended. cpu is idle.

Regarding the opaque surfaces. hmm... No idea how the window stacking works. the apps itself are opaque for sure. not sure if Mir or unity-mir sets them to transparent when inactive.

[Michael Zanetti (mzanetti)]

also, it doesn't matter which apps. Its really not hard to reproduce. Get a Nexus 4 and start 5+ apps and use the UI a bit.

[Daniel van Vugt (vanvugt)]

No problem. There's plenty more things we can test and look for yet. I would certainly hope Mir is capable of running faster than it does today on the N4.

[Gerry Boland (gerboland)]

App surfaces not opaque yet, as mentioned in https://bugs.launchpad.net/mir/+bug/1227739
That might be a low-hanging solution to fix this.

[Andreas Pokorny (andreas-pokorny)]

Not opaque - and buffers are really large. If they do not get mipmapped the GPU cache will hate us.
With additional and enabled traces I get the following logs with 9 applications started:

ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=friends-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.sudoku_sudoku_1.0.142)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=gallery-app)
ApplicationScreenshotProvider - working with size 768 x 1280
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.calendar_calendar_0.4.182)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.calculator_calculator_0.1.3.206)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=camera-app)
ApplicationScreenshotProvider - working with size 768 x 1280
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=webbrowser-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=address-book-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=dialer-app)
ApplicationScreenshotProvider - working with size 768 x 1222

Those are the screenshots requested from the scene that shows the application thumbnails.

When I click on application (here dialer-app) I get:
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=dialer-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=gallery-app)
ApplicationScreenshotProvider - working with size 768 x 1280
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.calendar_calendar_0.4.182)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.calculator_calculator_0.1.3.206)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=com.ubuntu.sudoku_sudoku_1.0.142)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=camera-app)
ApplicationScreenshotProvider - working with size 768 x 1280
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=webbrowser-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=address-book-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=dialer-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestPixmap (this=0x47bd58f8, id=friends-app)
ApplicationScreenshotProvider - working with size 768 x 1222
ApplicationScreenshotProvider::requestP...

[Andreas Pokorny (andreas-pokorny)]

I stand corrected - even with empty QImages scrolling is bumpy

[Andreas Pokorny (andreas-pokorny)]

I added per GLRenderer::render traces - mir has to render each of the paused application surfaces one by one with the phone shell on top. Each of them take between 1.8 and 2.8 ms just within the render function... depending on other interactions we might miss the 16 ms after having four suspended applications (== 5 nearly fullscreen surfaces to blend)

[Daniel van Vugt (vanvugt)]

Sounds like this is still bug 1227739, not fully resolved (which we already knew). So marking as duplicate for now.