When an application is suspended or closed it causes a large UI stutter

[Andrew Hayzen]

When an application is suspended or closed it causes a large UI stutter.

What happened:
1) Open multiple applications (eg Browser and Music)
2) Switch from Browser to Music
3) Scroll up/down a listview
4) Around 2 seconds after switching from Browser to Music the process is suspended and it can be observed that a UI stutter occurs

What I expected to happen:
At step 4) for there to be no stutter in the UI

Note that this also occurs if you close an application, and happens when switching from an application to the scopes.

$ system-image-cli -i
current build number: 169
device name: mako
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2015-11-23 01:08:21
version version: 169
version ubuntu: 20151120.1
version device: 20150911
version custom: mako-1.1

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Michael Zanetti (mzanetti)]

This is the relevant debug output while the stuttering occurs.

qtmir.surfaces: MirSurface["webbrowser-app"]::stopFrameDropper()
qtmir.applications: Application::setInternalState - appId= "webbrowser-app" state= SuspendingWaitProcess
qtmir.applications: TaskController::suspend - appId= "webbrowser-app"
qtmir.applications: Application::setInternalState - appId= "webbrowser-app" state= Suspended
qtmir.applications: ApplicationManager::onAppDataChanged: Received "state" update "webbrowser-app"

[Andrea Bernabei (faenil)]

I'm currently seeing many-seconds delay on rc-proposed r308 on Krillin...

Not sure how I got there (yet) but when I switched from one app to others, it was freezing for a few seconds every time...pretty annoying :)

[Andrea Bernabei (faenil)]

In my case, I was continuously switching between Telegram and Twitter apps (post a tweet, then switch, chat a bit, then switch, etc)...could it have something to do with the browser? (since it's also part of the usecase presented by the bug author)

[Andrew Hayzen (ahayzen)]

Agreed, from playing about with this for a while now, anything that is using oxide (webbrowser or webapp) seems to cause a very large and noticeable delay. Although it should be confirmed that other apps are not susceptible to this.

[Albert Astals Cid (aacid)]

Cut the rope (which is also oxied based) is also a big reproducer of this bug when switching from it to somewhere else (in case you need help with reproducing)

[Michał Sawicz (saviq)]

<ted> So I think that the answer is, yeah, we do that syncronously.
 We do a dbus call to cgmanager to get the list of pids and try to write their proc value.
 If we fail, then we need a setuid helper for things like oxide.
 So it could be that spawning that helper is part of what is causing a delay
 I'm not sure how to do it another way though.
 We're not blocking on it running, the overhead is just starting it.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Daniel van Vugt (vanvugt)]

Sounds like bug 1640443?

[Pat McGowan (pat-mcgowan)]

The silo works for me mx4 on proposed