1696379 - Jank when large animated GIFs come into view on Adreno 330

Status: NEW

(Core :: Graphics: WebRender, defect, P3)

Description

[Henrik Winnemöller]

Steps to reproduce

1. (WR is rolled out on Adreno 3xx since Bug 1706267)
2. Open https://github.com/mozilla-mobile/fenix/issues/2370.
3. Scroll down to ensure that all shaders are compiled.
4. Scroll to the very top, begin profile capture and slowly scroll down.

Expected result
Website scrolls smoothly.

Actual result
Jank is experienced when the large animated GIFs come into view. I also experience some jank on OpenGL compositor, but not that severe. I do not see any failure logs besides "failed program_binary issues".

Profile
https://share.firefox.dev/2MLvXyB

Device Info
Vendor and Model: Sony Xperia Z2
OS version: Android 6.0.1
GPU model: Adreno 330 (WebRender Compositing)
Number of cores: 4 (Snapdragon 801)

Fenix version
Nightly 210303 17:03 (Build #2015796553)
AC: 74.0.20210302143118, cce45da40
GV: 88.0a1-20210302034602
AS: 72.1.0

Comment 1

[Jamie Nicol [:jnicol]]

The profile shows most of the time is spent memcpying the image data in to a PBO, the upload itself appears to be happening asynchronously as intended.

I tried only copying a single row of data in to the PBO, to check whether the memcpy is including some time taken to allocate or map the buffer. But that was much faster, so it really does seem to be the copy itself taking too long. I also tried doing the copy as a single memcpy call, rather than row-by-row. This means the stride is incorrect so the picture looks like garbage, but would tell us whether multiple copies is the reason why it's slow. But that was still slow, so multiple copies are not the problem.

I also tried using immediate uploads rather than PBOs. This was much better: it avoids the catastrophic memcpy, but instead we get a (not nearly as) slow glTexSubImage2D. We're never going to hit 60FPS with immediate uploads in general, but perhaps as a quick fix when images are above a certain size we want to use immediate uploads.

As a longer term fix, perhaps we should be decoding these frames in to a ANativeWindow/Surface on the content side, and using the corresponding SurfaceTexture as an external image in webrender to render them?

cc Andrew as he had some ideas on Element.