Webbrowser slow scroll and artifact rendering on freiza

[Bill Filler]

Copied from private avila bug: https://bugs.launchpad.net/avila-private/+bug/1547569
STEPS:
1. Install the latest image
2. Open the browser
3. Goto ubuntu.com
4. Wait for the page to load
5. Scroll the page

EXPECT
Smooth scrolling and rendering as seen on arale and krillin

ACTUAL:
Very slow render time on most site with a lot of content
Scrolling is glitchy and seems to want to fresh render each page as it is scrolled

This is most prominently seen on ubuntu.com but also ebay and amazon webapps.

Webbrowser seems to display the issue the most although I beleive it is more likely to be the graphics stack somewhere, tvoss believe that perfservice will hopefully solve the issue.

[Pat McGowan (pat-mcgowan)]

Any updates?

[Chris Coulson (chrisccoulson)]

Basically, we're falling back to software compositing on Freiza for a couple of reasons:

- We don't set up a share context on devices where Chromium uses virtual GL contexts (essentially, all client-side GL contexts are backed by one single GL context on the GPU service side), as this is normally done to work around share-group related driver bugs.
- The graphics driver isn't advertising the extensions we require for the EGLImage compositing path (EGL_KHR_image, EGL_KHR_image_base and EGL_KHR_gl_texture_2D_image).

This means that neither of the 2 accelerated compositing paths that Oxide has available currently work on this device.

[Thomas Voß (thomas-voss)]

As pointed out in, we should check why:

  EGL_KHR_image, EGL_KHR_image_base and EGL_KHR_gl_texture_2D_image

are not reported by the driver and rule out issues.

[Pat McGowan (pat-mcgowan)]

assigning back as it seems an oxide issue

[Dave Morley (davmor2)]

I assume any fix here will most likely work on other affected systems like arale?

[Chris Coulson (chrisccoulson)]

So it seems that the required extensions are reported by the driver, but they're not reported in chrome://gpu/. I'll report another bug for that.

I'm not sure what's going on with the current Oxide version (1.12) - I'm not doing any debugging on that.

My trunk build of Oxide runs with accelerated compositing, but it's using a share group when it shouldn't be - I've reported bug 1552376 for that. It doesn't exhibit the out-of-order frames I see with Oxide 1.12, but performance still isn't great.

[Chris Coulson (chrisccoulson)]

Missing information in chrome://gpu/ is bug 1552657

[Chris Coulson (chrisccoulson)]

I added a few trace events in Oxide earlier that would aid debugging in chrome://tracing/. Unfortunately, there's no way to save the trace from the browser for offline viewing (as it's incompatible with the way we do downloads) and I can't take a screenshot of it because screenshots on Freiza are broken.

I'll try to describe the first main observation:

1) After the webview compositor has finished producing a frame, it calls in to oxide::CompositorSingleThreadProxy::SwapCompositorFrame.
2) At this point, we insert a fence in the command stream and flush.
3) After the fence is signalled, we run oxide::CompositorSingleThreadProxy::ContinueSwapGLFrame.
4) This ends up entering QQuickItem::update for the webview, which schedules a sync.
5) At the end of the sync (OxideQQuickWebView::updatePaintNode), we call back in to the webview compositor to notify it that the swap has completed and that the old buffer can be used as the back buffer.

I've added a trace event to time how long it takes to get from 2 to 3 - it's currently ~5-6ms. This is basically how long it takes the GPU service to execute the commands that were just flushed for compositing the webview, and isn't particularly out of the ordinary.

I've also added a trace event to time between 4 and 5, which is basically timing how long it takes between scheduling an update and the sync completing, and I'm seeing regular delays of up to 30ms. Within 5ms of scheduling an update (calling QQuickItem::update), the main thread appears to be completely blocked (although, I am only looking at compositor events in chrome://tracing/).

Whilst there are optimizations we can work in Oxide, the main bottleneck here appears to be something else.

[Chris Coulson (chrisccoulson)]

I'm also regularly seeing GLES2DecoderImpl::RestoreFramebufferBindings block the GPU thread for in excess of 20ms, which is weird. All it's doing is basically calling glBindFramebufferEXT

[Chris Coulson (chrisccoulson)]

This is a photo of a trace that shows the issue in comment 8

[Chris Coulson (chrisccoulson)]

And a photo of a trace showing the issue in comment 9

[Chris Coulson (chrisccoulson)]

I've reported bug 1553302 as well now.

[Chris Coulson (chrisccoulson)]

I added some more trace events and confirm that the issue shown in the trace in comment 11 is occurring during this call to glBindFramebufferEXT, right here:

https://git.launchpad.net/~oxide-developers/oxide/+git/chromium/tree/gpu/command_buffer/service/gles2_cmd_decoder.cc?id=31a49d82d9c36d5f18095aa6fe0f03ed5fc0905e#n4676

I've no idea why that would take so long, but this is driver stuff now.

[Chris Coulson (chrisccoulson)]

Note, somebody else needs to take a look at this now...

[David Barth (dbarth)]

I pinged the commercial team to ask about a possible driver update

[Chris Coulson (chrisccoulson)]

I ran the browser with QSG_RENDER_TIMING=1, and I see timings like this:

qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 30ms, sync=0, render=2, swap=28 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=14, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 39ms, sync=0, render=1, swap=37 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=27, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 39ms, sync=0, render=1, swap=37 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=25, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=4ms, preprocess=0, updates=0, binding=2, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 39ms, sync=0, render=5, swap=34 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=26, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 40ms, sync=0, render=1, swap=38 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=29, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=3ms, preprocess=0, updates=0, binding=0, rendering=3
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 27ms, sync=2, render=4, swap=21 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=10, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 25ms, sync=0, render=2, swap=22 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=10, animations=0 - (on Gui thread) BrowserWindow_QMLTYPE_1_QML_207(0xab14ee20)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 34ms, sync=0, render=1, swap=32 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with...

[Chris Coulson (chrisccoulson)]

Marking the Oxide task invalid for now - I've split out Oxide issues in to new bugs

[John McAleely (john.mcaleely)]

So Oxide (well, chrome proper) has run on this GPU family in both native (Samsung Chromebook) and Android forms (Nexus 10), and perhaps others.

Does this bug occur there too? Or is it somehow only emergent on our stack only?

[Gerry Boland (gerboland)]

I agree with Chris' assessment. eglSwapBuffers blocking for so long (over 32ms, i.e. 2 frames at 60Hz) is causing Qt's main loop to block, compounding the stutter.

[David Barth (dbarth)]

loicm kindly pointed me to his qml magnifier demo which should help expose the FBO performance issue and clarify where the problem is:

https://developer.ubuntu.com/en/blog/2015/04/28/magnifying-glass-qml/

[John McAleely (john.mcaleely)]

Until this is a repro written only in C linking the OpenGLES & EGL libraries (and glibc or bionic), no gpu vendor will take it very seriously. No-one appears to have addressed my comment in #18 - why does oxide not see this when it meets this GPU on other OS platforms?

[David Barth (dbarth)]

Oxide only runs on Ubuntu.

But that's still a valid question : if that GPU was to expose such a slowdown on another OS (Android say), the upstream Blink code would probably have marked it with a quirk or blacklist to signal the bad performance of the driver.

So either we end up calling glBindFramebufferEXT in a context quite different from the Android one, exposing an unknown driver bug. Or there is something making that context quite different like Mir or Unity ?

@ChrisCoulson or @gerboland: could one of you guys have a try at distilling that into a C test case?

[Chris Coulson (chrisccoulson)]

The main reason Oxide is slow is because the browser's UI thread is being blocked for long periods of time due to an issue *outside* of Oxide.

As a quick test, I just ran the address book app with QSG_RENDER_TIMING=1, and it demonstrates exactly the same issue as the browser - the render thread regularly being blocked for over 20ms and sometimes up to 40ms in eglSwapBuffers, which causes the UI thread to be blocked, eg:

qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 41ms, sync=0, render=5, swap=35 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=36, animations=0 - (on Gui thread) QQuickView(0x385ef0)

Scrolling in address book app is also very janky (like with every other app and the shell on my M10). I'm not the only person seeing this, am I?

[Chris Coulson (chrisccoulson)]

Just to make sure it wasn't a one off with the address book app, I did it again. Here's a few more data points from the log:

qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 8ms, sync=0, render=1, swap=7 - (on render thread)
qt.scenegraph.time.renderer: time in renderer: total=6ms, preprocess=0, updates=0, binding=0, rendering=6
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 115ms, sync=0, render=6, swap=109 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=120, animations=0 - (on Gui thread) QQuickView(0x385ef0)
qt.scenegraph.time.renderer: time in renderer: total=2ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 13ms, sync=0, render=2, swap=11 - (on render thread)
qt.scenegraph.time.texture: plain texture uploaded in: 0ms (26x26), bind=0, convert=0, swizzle=0 (BGRA->BGRA), upload=0, mipmap=0
qt.scenegraph.time.renderer: time in renderer: total=3ms, preprocess=0, updates=0, binding=0, rendering=3
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=41, animations=0 - (on Gui thread) QQuickView(0x385ef0)
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 29ms, sync=0, render=4, swap=25 - (on render thread)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
APP_ID isn't set, the handler ignored
ubuntumirclient: Got invalid serialized mime data. Ignoring it.
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 40ms, sync=0, render=1, swap=39 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=21, animations=0 - (on Gui thread) QQuickView(0x385ef0)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 41ms, sync=0, render=1, swap=39 - (on render thread)
qt.scenegraph.time.renderer: time in renderer: total=0ms, preprocess=0, updates=0, binding=0, rendering=0
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=38, animations=0 - (on Gui thread) QQuickView(0x385ef0)
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 40ms, sync=0, render=1, swap=39 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=32, animations=0 - (on Gui thread) QQuickView(0x385ef0)
qt.scenegraph.time.renderer: time in renderer: total=1ms, preprocess=0, updates=0, binding=0, rendering=1
qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop in 42ms, sync=0, render=2, swap=40 - (on render thread)
qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop, polish=0, lock=0, blockedForSync=36, animations=0 - (on Gui thread) QQui...

[David Barth (dbarth)]

And based on John's earlier remark, ie that the same HW and drivers do
perform properly with another OS, then it means that Ubuntu components
between apps and driver/HW are introducing that extra 20/40ms delay. Mir?
Unity8? Something else?

On Tue, Apr 19, 2016 at 8:47 PM, Chris Coulson <email address hidden>
wrote:

> The main reason Oxide is slow is because the browser's UI thread is
> being blocked for long periods of time due to an issue *outside* of
> Oxide.
>
> As a quick test, I just ran the address book app with
> QSG_RENDER_TIMING=1, and it demonstrates exactly the same issue as the
> browser - the render thread regularly being blocked for over 20ms and
> sometimes up to 40ms in eglSwapBuffers, which causes the UI thread to be
> blocked, eg:
>
> qt.scenegraph.time.renderloop: Frame rendered with 'threaded' renderloop
> in 41ms, sync=0, render=5, swap=35 - (on render thread)
> qt.scenegraph.time.renderloop: Frame prepared with 'threaded' renderloop,
> polish=0, lock=0, blockedForSync=36, animations=0 - (on Gui thread)
> QQuickView(0x385ef0)
>
> Scrolling in address book app is also very janky (like with every other
> app and the shell on my M10). I'm not the only person seeing this, am I?
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1550371
>
> Title:
> Webbrowser slow scroll and artifact rendering on freiza
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1550371/+subscriptions
>

[kevin gunn (kgunn72)]

@dbarth - so did someone run the exact same gl/egl call sequence on android and prove that the behavior is not exhibited?
i do not see that data here. so we're just making guesses.

@john-mc - i agree a distilled c-app would probably be beneficial

[David Barth (dbarth)]

@kgunn: no, we haven't produced that data, but I assume you guys have some
egl unit tests handy to get a confirmation.

I think we're making reasonable guesses here: Chris has shown that all apps
are affected, not just Oxide. And John indicates that the very same driver
binaries work on Android, so there aren't so many things between apps and
drivers. And definitely that is not an Oxide, nor a Blink bug.

On Wed, Apr 20, 2016 at 2:59 PM, kevin gunn <email address hidden>
wrote:

> @dbarth - so did someone run the exact same gl/egl call sequence on
> android and prove that the behavior is not exhibited?
> i do not see that data here. so we're just making guesses.
>
> @john-mc - i agree a distilled c-app would probably be beneficial
>
> ** No longer affects: unity8 (Ubuntu)
>
> --
> You received this bug notification because you are a member of Ubuntu
> WebApps bug tracking, which is subscribed to Oxide.
> https://bugs.launchpad.net/bugs/1550371
>
> Title:
> Webbrowser slow scroll and artifact rendering on freiza
>
> Status in Canonical System Image:
> Confirmed
> Status in Mir:
> New
> Status in Oxide:
> Invalid
> Status in webbrowser-app package in Ubuntu:
> Invalid
>
> Bug description:
> Copied from private avila bug:
> https://bugs.launchpad.net/avila-private/+bug/1547569
> STEPS:
> 1. Install the latest image
> 2. Open the browser
> 3. Goto ubuntu.com
> 4. Wait for the page to load
> 5. Scroll the page
>
> EXPECT
> Smooth scrolling and rendering as seen on arale and krillin
>
> ACTUAL:
> Very slow render time on most site with a lot of content
> Scrolling is glitchy and seems to want to fresh render each page as it
> is scrolled
>
> This is most prominently seen on ubuntu.com but also ebay and amazon
> webapps.
>
> Webbrowser seems to display the issue the most although I beleive it
> is more likely to be the graphics stack somewhere, tvoss believe that
> perfservice will hopefully solve the issue.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1550371/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
> More help : https://help.launchpad.net/ListHelp
>

[kevin gunn (kgunn72)]

Does anyone know the circa of these gpu drivers?
my assumption is we take a snapshot of their android bsp to get them, but do we know if they are latest and greatest?

we're kinda of at the libhybris/gpu level now - so just thought it's possible there's driver bug fixes we may benefit from
anyone know?

[John McAleely (john.mcaleely)]

OpenGLES will report a version (containing the string rXpX for a mali
driver). that can be cross checked against malideveloper.com to learn their
age.

On 20 April 2016 at 17:17, kevin gunn <email address hidden> wrote:

> Does anyone know the circa of these gpu drivers?
> my assumption is we take a snapshot of their android bsp to get them, but
> do we know if they are latest and greatest?
>
> we're kinda of at the libhybris/gpu level now - so just thought it's
> possible there's driver bug fixes we may benefit from
> anyone know?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1550371
>
> Title:
> Webbrowser slow scroll and artifact rendering on freiza
>
> Status in Canonical System Image:
> Confirmed
> Status in Mir:
> New
> Status in Oxide:
> Invalid
> Status in webbrowser-app package in Ubuntu:
> Invalid
>
> Bug description:
> Copied from private avila bug:
> https://bugs.launchpad.net/avila-private/+bug/1547569
> STEPS:
> 1. Install the latest image
> 2. Open the browser
> 3. Goto ubuntu.com
> 4. Wait for the page to load
> 5. Scroll the page
>
> EXPECT
> Smooth scrolling and rendering as seen on arale and krillin
>
> ACTUAL:
> Very slow render time on most site with a lot of content
> Scrolling is glitchy and seems to want to fresh render each page as it
> is scrolled
>
> This is most prominently seen on ubuntu.com but also ebay and amazon
> webapps.
>
> Webbrowser seems to display the issue the most although I beleive it
> is more likely to be the graphics stack somewhere, tvoss believe that
> perfservice will hopefully solve the issue.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1550371/+subscriptions
>

[Daniel van Vugt (vanvugt)]

I'm not familiar with Frieza so can't test any of this myself...

If the problem is eglSwapBuffers taking two frames, then that's the same kind of thing we saw in bug 1563287. Even though we measured the client (Unity8 itself) was taking two frames, the problem was actually the server (USC) being so slow that every client swap took 2-3 frames. It's quite reasonable to imagine bug 1563287 would also manifest in client=web-browser and server=unity8.

So I suggest trying the fix for bug 1563287 as soon as it's out. Kevin's fix for that also explicitly mentions frieza

Secondly, what's the oldest working image for frieza? Was it ever fast or never been?

[Chris Coulson (chrisccoulson)]

Freiza has been slow since the day I received my device, although I don't recall what image I first used on it.

It's interesting that there are issues with EGL sync fences - I'm pretty sure we're using these in Oxide on this device. They're blacklisted on krillin with the comment "Testing fences was broken on Mali ES2 drivers" and links to 2 private bugs and 2 public bugs of questionable relevance (https://bugs.chromium.org/p/chromium/issues/detail?id=373360 and https://bugs.chromium.org/p/chromium/issues/detail?id=371530)

[Chris Coulson (chrisccoulson)]

I've installed the packages from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-019/ on my device, and it seems to have significantly improved scrolling in the browser

[kevin gunn (kgunn72)]

thanks for that feedback, interesting news indeed.
Do you happen to have any measured data for that scrolling improvement?

[Daniel van Vugt (vanvugt)]

You will also want this smoothness fix if you're using touch:
https://code.launchpad.net/~vanvugt/unity8/fix-1556763/+merge/288891

[Chris Coulson (chrisccoulson)]

I don't have any measured data for the scrolling improvement - I can probably do a chrome://tracing/ run again though

[kevin gunn (kgunn72)]

OK, after quite a bit of research the bottom line is that this is a mali quirk.
There are 2 potential ways both are by specification allowed to sync with the driver - which resulted in a performance issue (covered by this bug) and a "correctness issue" covered by bug 1573014
The performance issue is now addressed by the quirk added to mir0.22 for all the devices with mali gpu.
Further work will continue on bug 1573014 as there are other suspicions from data collected here that the mali driver has other issues.

[David Barth (dbarth)]

Thanks Kevin & Team !

On Wed, Apr 27, 2016 at 5:31 PM, kevin gunn <email address hidden>
wrote:

> OK, after quite a bit of research the bottom line is that this is a mali
> quirk.
> There are 2 potential ways both are by specification allowed to sync with
> the driver - which resulted in a performance issue (covered by this bug)
> and a "correctness issue" covered by bug 1573014
> The performance issue is now addressed by the quirk added to mir0.22 for
> all the devices with mali gpu.
> Further work will continue on bug 1573014 as there are other suspicions
> from data collected here that the mali driver has other issues.
>
> ** Changed in: mir
> Milestone: None => 0.22.0
>
> ** Also affects: mir/0.22
> Importance: Undecided
> Status: New
>
> ** Changed in: mir/0.22
> Milestone: None => 0.22.0
>
> ** Changed in: mir/0.22
> Status: New => Fix Committed
>
> ** Changed in: mir
> Status: New => Fix Committed
>
> ** Changed in: canonical-devices-system-image
> Status: Confirmed => Fix Committed
>
> ** Branch linked: lp:mir/0.22
>
> --
> You received this bug notification because you are a member of Ubuntu
> WebApps bug tracking, which is subscribed to Oxide.
> https://bugs.launchpad.net/bugs/1550371
>
> Title:
> Webbrowser slow scroll and artifact rendering on freiza
>
> Status in Canonical System Image:
> Fix Committed
> Status in Mir:
> Fix Committed
> Status in Mir 0.22 series:
> Fix Committed
> Status in Oxide:
> Invalid
> Status in webbrowser-app package in Ubuntu:
> Invalid
>
> Bug description:
> Copied from private avila bug:
> https://bugs.launchpad.net/avila-private/+bug/1547569
> STEPS:
> 1. Install the latest image
> 2. Open the browser
> 3. Goto ubuntu.com
> 4. Wait for the page to load
> 5. Scroll the page
>
> EXPECT
> Smooth scrolling and rendering as seen on arale and krillin
>
> ACTUAL:
> Very slow render time on most site with a lot of content
> Scrolling is glitchy and seems to want to fresh render each page as it
> is scrolled
>
> This is most prominently seen on ubuntu.com but also ebay and amazon
> webapps.
>
> Webbrowser seems to display the issue the most although I beleive it
> is more likely to be the graphics stack somewhere, tvoss believe that
> perfservice will hopefully solve the issue.
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1550371/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
> More help : https://help.launchpad.net/ListHelp
>

[Daniel van Vugt (vanvugt)]

TLDR:
The fix was the same as bug 1563287. So you can refer to bug 1563287 to see the history.

[kevin gunn (kgunn72)]

this should have been marked ota10

[kevin gunn (kgunn72)]

rather it was a point release

[Daniel van Vugt (vanvugt)]

Correction: Mir 0.21.1 does not exist yet, but it might in future.