Closed Bug 1809738 Opened 11 months ago Closed 10 months ago - stuttering and input lag - Caused by backdrop-filter


(Core :: Graphics: WebRender, defect)




111 Branch
Tracking Status
firefox110 --- verified
firefox111 --- verified


(Reporter: mleclair, Assigned: jnicol)


(Blocks 1 open bug)



(2 files)

From github:

Steps to reproduce

Visiting the mobile twitter site and scrolling around

Expected behavior

Fast device and 120hz screen should provide smooth scrolling like other sites

Actual behavior

The website is very stuttery and has input lag.
If I view the desktop site it's fine.
It seems related to the backdrop-filter CSS performance. If I block backdrop-filter on ublock origin to stop the blur effect on the Twitter mobile page it will work correctly and be very smooth.

Device information

  • Android device: 13 (2023-01-05 patch) - Pixel 7 Pro
  • Fenix version: 108.1.1 - present in beta and nightly.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Blocks: gfx-triage

Testing on a Pixel 6a, which has a similar enough GPU to the reporter, but only a 60Hz screen.

Gecko profile doesn't show much interesting: . Lots of time spent in glBindFramebuffer typically indicates we are GPU bound.

The HUD profiler with gpu time queries enabled backs that up: 24ms avg GPU time with backdrop filter enabled, 2ms with it disabled. That's just very gently scrolling up and down a quarter screen each way.

Backdrop filter being enabled interferes with picture caching significantly - the header and footer bars are no longer in a different slice than the main scrollable content. Meaning the tiles at the bottom and top of the screen are fully invalidated every scroll, rather than nothing being invalidated at all.

Desktop has this exact same picture caching problem, but perhaps due to more powerful GPUs we have been able to get a way without users noticing.

Glenn, any thoughts on why picture caching is negatively affected by backdrop-filter?

Flags: needinfo?(gwatson)

For comparison, on my Samsung S22 (with the AMD Xclipse GPU) the frame rate is much better, consistently hitting 120fps. We still have the picture caching issue, of course. So something on this page is slow to render on Mali, could be the backdrop filter implementation, or could be something else. And then because picture caching isn't working optimally, we're rendering more than we should be which exacerbates the issue.

The backdrop-filter primitive in a given slice needs to be able to read back the content conceptually underneath it (to feed as input to the filter chain). This causes us to collapse slices in the case of a backdrop-filter, so it sounds like expected behavior.

There are some cases where we could do better here long term, but in general this sounds like it's expected - it can just be an expensive effect to draw (though in this case it sounds like there might be a bug causing it to be even more expensive than expected).

Flags: needinfo?(gwatson)

Or more precisely, the picture-caching config you observed sounds like it's expected, and that means that backdrop-filter does typically require more GPU work than when backdrop-filter isn't present, but that's not typically expensive enough to explain what is being reported here. It does sound like there is something else going on, especially given comment #2.

No longer blocks: gfx-triage

I'll attempt to repro this.

Severity: -- → S3
Flags: needinfo?(ahale) is a profile on my pixel 6 pro

We currently set a scissor rect when clearing render targets, as this
was measured to be a performance win on some GPUs. On Mali, however,
it is better to perform a full, non-scissored clear of a render target
immediately after binding it, as this allows the driver to omit
reading the previous contents in to tile memory. This patch makes it
so that by default we perform the non-scissored clear on Mali, and
retain the scissor on all other GPUs. The existing
enable_clear_scissor option can be used by the embedder to override
the default value.

Of particular note, this massively improves the performance of twitter
on Mali G710 (eg Pixel 7), where the blur backdrop-filter uses several
intermediate render targets and the scissored clear causes noticable

Assignee: nobody → jnicol
Pushed by
Avoid using scissor rect when clearing render targets on Mali GPUs. r=gfx-reviewers,lsalzman
See Also: → 1814344

I should have mentioned, I got my hands on a Pixel 7 (Mali G710), and the issue is much worse than on the Pixel 6 (Mali G78). Comment 8 describes the cause of that.

There is still some general slowness when rendering twitter on a variety of devices, which does not appear to be caused by the backdrop filter directly, which perhaps we can address in follow-up bugs.

Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

Comment on attachment 9315232 [details]
Bug 1809738 - Avoid using scissor rect when clearing render targets on Mali GPUs. r?#gfx-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined: Slow performance for users with Mali G710 GPUs (eg Pixel 7 and Pixel 7 Pro) on twitter as well as many other websites that contain blur effects
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Minor change. Follows recommended practice on this GPU.
  • String changes made/needed:
  • Is Android affected?: Yes
Attachment #9315232 - Flags: approval-mozilla-beta?

Comment on attachment 9315232 [details]
Bug 1809738 - Avoid using scissor rect when clearing render targets on Mali GPUs. r?#gfx-reviewers

Approved for our last 110 beta, thanks.

Attachment #9315232 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

Verified on the latest Nightly 111.0a1 (2023-02-04) and on Beta 110.0b6 builds.
There are no issues on scrolling, no input lag, the site works smoothly.
Compared it to Chrome as well, and there were no noticeable differences.
Device used: Google Pixel 7 (Android 13).
Marking the ticket as verified.

Flags: needinfo?(ahale)
You need to log in before you can comment on or make changes to this bug.