​​### Basic information

Scrolling the Wikipedia on Fenix is slow if the native dark mode is enabled.

How to enable dark mode:

1. Go to https://en.m.wikipedia.org
2. Log into your account
3. Go to settings/user preferences (Open preferences).
4. Scroll down and access "Gadgets".
5. Enable "dark mode toggle" from "Appearance" section.
6. Enable "Core styling for dark mode..." from "Utility modules" section.

Performance recording (profile)

Profile URL: https://share.firefox.dev/3zx0ncq

System configuration:

OS version: Android 13
GPU model: Adreno 506
Number of cores: 4+4 (Qualcomm SDM632 Snapdragon 632)
Amount of memory (RAM): 4 GiB

More information

Instead of re-defining colors for their dark mode, Wikimedia is using a global filter. The problematic rule is

html,
html img,
html video,
html ogvjs,
html svg,
html iframe,
html .mw-no-invert,
html td .diffchange,
html .mwe-math-element,
html .wvui-typeahead-suggestion__thumbnail,
html .skin-minerva .mw-notification-visible .mw-notification-content,
html .cdx-menu-item__thumbnail,
html .cx-slitem__image,
html .mw-mmv-overlay,
html .mw-mmv-pre-image,
html .media-viewer .image img,
html .media-viewer .mw-file-description img,
html .mw-kartographer-map,
html .mw-kartographer-mapDialog-map,
html .list-thumb,
html .ext-related-articles-card-list .ext-related-articles-card-thumb {
  filter: invert(1) hue-rotate(180deg);
}

Having this filter on the entire page makes scrolling very sluggish.

This might just be a duplicate of bug 1193882 or other bugs, but since this applies nested filters to multiple elements, it could also be similar to bug 1600296 or something else, so I figured filing a new bug is a good idea.

Thanks so much for your help.

Seems like a CSS parsing issue.

The Performance Impact Calculator has determined this bug's performance impact to be high. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Android
Impact on site: Causes noticeable jank
Configuration: Specific but common
Page load impact: Some
Websites affected: Major
[x] Able to reproduce locally

The severity field is not set for this bug.
:jfkthame, could you have a look please?

For more information, please visit BugBot documentation.

Bas, I'm curious why you see this as a CSS parsing issue? In the profile in comment 0, it looks to me like it's primarily the Renderer thread in the GPU process that's the issue, with its composites often taking over 20ms; that'll definitely prevent us getting anywhere near 60fps, won't it?

(In reply to Jonathan Kew [:jfkthame] from comment #3)

Bas, I'm curious why you see this as a CSS parsing issue? In the profile in comment 0, it looks to me like it's primarily the Renderer thread in the GPU process that's the issue, with its composites often taking over 20ms; that'll definitely prevent us getting anywhere near 60fps, won't it?

You are correct. I missed the profile. Sorry about that! I should have realized this before. Moving components. I'm guessing the inversion filter causes WebRender to hit some kind of slow path, that probably isn't exclusive to Android but may affect it disproportionately. I'll let Jeff & Jamie comment on that.

Jamie's the better person to answer this.

We got a report about another site doing the same, https://ponepaste.org/8805.

This seems very much an @ahale thing!
In particular, what do you think the severity should be? I feel like an estimated S2.8 rounds to S3, especially if you're working on it already?

The profile shows some really slow weird stuff in the Renderer thread, in SwapBuffers and QuerySurface, so this feels very Jamie-targetted. :)

I'm working on making all filter graphs native in WebRender https://bugzilla.mozilla.org/show_bug.cgi?id=1409486 which would avoid any possible blob fallback happening here, however this bug may be something else and I'll let Jamie assess that.

If this filter chain is not being accelerated properly in WebRender we can fix that, but it looks like something else may be going on in the profile.

As for the severity, I can imagine an argument that this is S2 because accessibility features are being used on a popular website (Wikipedia), there is a mechanistic quirk here - on desktop people who need this type of dark mode experience would tend to use an extension (and the extension may be doing this slightly differently), but on mobile it's common to use site features such as this to get a dark mode experience, so the scope of impact may be largely specific to mobile users of wikipedia. It's hard to say whether S3 or S2 is more appropriate in this case.

I don't think we have any blob fallback: all the worker threads are completely idle.

The reporter had an Adreno 506 which is on the less-powerful end of the spectrum. I can reproduce on Samsung A51 (Mali G72), but not a Pixel 5 (Adreno 620) or Pixel 7 (Mali G710). So this isn't specific to a model of GPU, but rather occurs on less powerful devices. On the more powerful devices I do see the frame time increase by a couple of milliseconds, but we're still comfortably in budget.

The provided profile is consistent with being GPU or perhaps more specifically memory bandwidth bound. Given the page is quite simple I would lean towards the latter. Here is a profile on the A51 which is much more concentrated on glClear() clearing picture cache targets, which would validate that theory.

Enabling dark mode on both wikipedia and ponepaste.org results in picture caching no longer working. Instead of a single scrollable slice we appear to get 2 non-scrolling slices, meaning the entire page is invalidated when we scroll. On less powerful devices we cannot afford to do that. This is also the case on desktop. The question for those who understand picture caching slightly better is why we fail to create a scrollable slice, and can we fix that?

The severity field for this bug is set to S3. However, the Performance Impact field flags this bug as having a high impact on the performance.
:gw, could you consider increasing the severity of this performance-impacting bug? Alternatively, if you think the performance impact is lower than previously assessed, could you request a re-triage from the performance team by setting the Performance Impact flag to ??

For more information, please visit BugBot documentation.

The picture-cache issue sounds quite similar to bug 1836063 where CSS filters (opacity in that case) cause unnecessary picture-cache invalidation and slow scrolling with weak GPUs. A fix for that should be landing imminently

Excellent, hopefully it's the same issue! Thanks!

FWIW I don't think the performance impact flag here is accurate. Wikipedia is a major website but it only occurs if the user is signed in and enables dark mode. But I'll wait and see if bug 1836063 fixes this before requesting retriage.

I can replicate this issue on Raspberry Pi 4. However, I've just tested and sadly my fix for 1836063 doesn't resolve this.