Dash pauses/stutters during scope switching left/right

This happens especially on boot, when moving between scopes causes other scopes to load their content. Creation of the delegates seems to cause the UI thread to block.

isn't that this lp:~unity-team/unity8/flickables-speed-workaround ?

Unlikely. This bug was discovered two weeks after that branch had already landed.

The flickables-speed-workaround is just to make the speed/acceleration you can give a list the same through the UI, the problem here is that we have too many things being create when you switch to a new scope and that creation is happening in the main thread when it should ideally not be.

This bug was fixed in the package unity8 - 8.01+15.04.20141202-0ubuntu1

---------------
unity8 (8.01+15.04.20141202-0ubuntu1) vivid; urgency=low

  [ Michael Terry ]
  * Make sure that there is no window of opportunity for swiping away
    greeter before the lockscreen appears.
  * Don't allow dragging the greeter out from the left edge if it's
    hidden there. (LP: #1372952)

  [ Michał Sawicz ]
  * Move from Theme colour to direct UbuntuColors.orange for activity
    indicator and preview buttons

  [ Albert Astals ]
  * Use QImageReader not to load the image into memory twice (LP:
    #1384374)
  * Don't create the whole current scope delegates, just height * 3 (LP:
    #1384393, #1384374)
  * Make CroppedImageSizer async
  * Use ubuntu::connectivity::NetworkingStatus instead of
    QNetworkConfigurationManager
  * Compile with Qt 5.4 (LP: #1395636)

  [ Michael Zanetti ]
  * close previews and temp scopes on left edge/BFB (LP: #1391798)
  * make spread reversible (LP: #1368668, #1355284, #1368677)

  [ Andrea Cimitan ]
  * Different drag behaviour for not closable apps in spread (LP:
    #1368287)

  [ Daniel d'Andrada ]
  * Make UnityTestCase.touchFlick properly map event coordinates
 -- Ubuntu daily release <email address hidden> Tue, 02 Dec 2014 09:26:49 +0000

After having another look at this we'll need more time to investigate and find the right balance and a solution.

What you can see currently, the worse experience is happening when you swipe between scopes for the first time after the dash is loaded. This is because when you swiped from scope #1 to scope #2, scope #3 is queried and its contents created, which is a heavy enough operation to cause brief (or less brief) UI thread blocks resulting in the stutter.
After all scopes are loaded, however, you can see that swiping between them is smooth, even though they do grow the number of items to prepare for the user swiping down in that scope.

We need to spend the time to understand where the blocking comes from and reduce as close to 0 as possible, and if that's not possible, potentially employ a few workaround fixes by the use of timers to defer delegate creation or similar.

FWIW, this isn't as obvious on vivid as it is on RTM simply due to the number of available / installed scopes.

BTW, for detecting blocking (which may occupy zero CPU time), I've found Google Profiler is the only open source tool that actually gives useful answers (apt-get install google-perftools).

All other open source profilers tend to track CPU cycles, which is not helpful when dealing with real time problems like this.

We don't have immediate improvements in store for this I'm afraid. It will require further, deep, analysis on what's the blocking part in this situation. It also depends on the design direction we'll go for wrt dash/home.

Right, IMO this should be pulled off the RTM list for now.

while we may not have a solution this remains a critical issue I am surprised there is no way to speed at least the perception of the scope loading or offload to other threads as discussed

> while we may not have a solution this remains a critical issue I am
> surprised there is no way to speed at least the perception of the scope
> loading or offload to other threads as discussed

We've already offloaded everything we could identify, which improved the
situation a lot. We now need to spend more time finding which bits still
add to the UI getting blocked when scopes are queried. Just never had
the time yet, so no immediate solution.

Google Profiler is a good option. Unlike most profilers it actually measures real time, so if a delay is due to a blocking (but CPU-idle) call then Google Profiler will find it.

Since we have no plans to start working on this soon i'll unassign myself in case someone else wants to take this. I'm still subscribed to all the comments though.

@tsdgeos - let's just consider this covered under the kpi effort, loop back and update with results

also, do we want to consolidate/consider this bug a dupe under bug 1497611

Other way round. This bug is older and has more detail/history. De-duplicate under this one.

from bug that was duplicated. one important comment i'd like to make sure gets highlighted here is
https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1497611/comments/7

also, wrt https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1497611/comments/9 that is something for the design team, they've spent quite a bit of time on user testing so any design changes forthcoming really are based on user data and verified preferences.

Can someone test this in a recent rc-proposed?

Not much ago a fix to the glyph generation went in
https://code.launchpad.net/~aacid/qtubuntu/turbo_workaround/+merge/294531 (and prerequisites)

and that fixes the stutering between scopes for me, but since stuttering is always a bit depending on the individual perception i'd like someone else to give it a try before closing this bug.

It definitely stutters on Krillin, rc-proposed, r356, especially when the scope views are not launched/cached yet.

I also get consistently bad framerate on scopes such as the Music scope (I have no music in the phone, so it's showing "New albums from 7Digital" and "Popular tracks on Soundcloud", although that is more of a rendering performance issue

stutters "when the scope views are not launched/cached yet" is this something we have ideas for? or are we stuck with a particular threading model here causing the rendering to get choked on the network & jpg decode?

also @faenil I'd be interested in your numbers on "bad frame rate for Music" (and i presume also krillin?)

> It definitely stutters on Krillin, rc-proposed, r356, especially when the scope views are not launched/cached yet.

Which scopes? It's really smooth here with the default scopes after a reboot.
Can you check the "[PERFORMANCE]: Last frame took" in /unity8-dash.log? How many if any at all do you get when swipin?

> I also get consistently bad framerate on scopes such as the Music scope

This is vertical swiping, right? Nothing to do with this bug if so, open a new bug if you want to :)

> stutters "when the scope views are not launched/cached yet" is this something we have ideas for?

I just don't get it to stutter anymore with the default scopes, i'm going to need help reproducing it so it can be fixed.

There is a chance the [PERFORMANCE] logger needs some tweaking/debugging.

I have just tried rebooting the phone.

I had multiple half-second or full-second freezes when horizontally scrolling between scopes, yet the [PERFORMANCE] logger only reported 3-4 "69ms to render" or "75ms to render" which was clearly not was I was seeing on screen.

The lags were many more than the 3-4 reported by the logger, and of *much* longer duration.

I will post more details as I have them. I will also try with Qt's env variables for performance debugging

@Albert and @Kevin: please find the full log attached.

I had a quick look, the main thread is chocking on the polish phase.
So it seems a layout performance problem, unless we're using Canvas in the QML code (Canvas does the rendering in the polish method, iirc)

Examples from the log:

3.4 seconds polish phase here
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=3479, lock=0, blockedForSync=78, animations=24 - (on Gui thread) QQuickView(0x7a98a0)
qt.scenegraph.time.glyph: distancefield: 29 glyphs prepared in 23ms, rendering=15, upload=8
Pre-populating scope "com.canonical.elpais_ELPAIS"
qt.scenegraph.time.texture: atlastexture uploaded in: 0ms (94x20)

or

1.3sec polish phase
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)
<Unknown File>:138:1: QML Label: Binding loop detected for property "height"
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=1297, lock=0, blockedForSync=40, animations=119 - (on Gui thread) QQuickView(0x7a98a0)
flushUpdates: "com.canonical.scopes.engadget_engadget" #results = 25 finalize: true
Adding # 25 results to category "root"
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)

or

1.285sec polish phase
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)
qt.scenegraph.renderloop: - lock for sync
qt.scenegraph.renderloop: - wait for sync
qt.scenegraph.renderloop: (RT) WM_RequestSync
qt.scenegraph.renderloop: (RT) --- done processEventsAndWaitForMore()
qt.scenegraph.renderloop: (RT) syncAndRender()
qt.scenegraph.renderloop: (RT) - updatePending, doing sync
qt.scenegraph.renderloop: (RT) sync()
qt.scenegraph.renderloop: (RT) sceneGraphChanged
qt.scenegraph.renderloop: (RT) - sync complete, waking Gui
qt.scenegraph.renderloop: (RT) - rendering started
qt.scenegraph.renderloop: - unlock after sync
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=1285, lock=0, blockedForSync=32, animations=0 - (on Gui thread) QQuickView(0x7a98a0)
flushUpdates: "com.canonical.scopes.reddit" #results = 70 finalize: true
Last result index= 30 category "posts"
qt.scenegraph.renderloop: update from item QQuickView(0x7a98a0)
qt.scenegraph.renderloop: - posting update
Added # 70 results (called with 100 ), current results#= 100

See the 3+ secs polish time, that's the kind of freezes I'm seeing. There are also multiple 1+sec and 0.1secs+ of polish times in the log.

There are also many examples of
<Unknown File>:128:1: QML Label: Binding loop detected for property "height"

and
<Unknown File>:121:2: QML Icon: Binding loop detected for property "width"

Those could be disturbing the polish phase, although they're likely not the cause of *all* the freezes.

Yes, i'm aware of this long polish times, it's just that you won't "see" them if you wait enough time between switching from scope to scope.

Marking as won't fix as there is a completely new design for this.