User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

I opened settings in firefox, and firefox is using grayscale in settings font's ignoring my rgb settings (i have rgb antialias setting enabled).

Actual results:

I opened settings in firefox, and firefox is using grayscale in settings font's ignoring my rgb settings (i have rgb antialias setting enabled).

Expected results:

Firefox should respect my fonts settings when rendering fonts in settings.

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

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

For more information, please visit auto_nag documentation.

Thanks for the bug report. Indeed, it looks to me like we're using grayscale antialiasing here (e.g. for the words "General" and "Startup" at the very top of about:preferences#general).

I'll attach a zoomed-in screenshot of what I'm seeing in Firefox settings.

As Glenn noted in bug 1763411 comment 8, WebRender (Firefox's graphics backend) falls back to grayscale antialiasing under a variety of conditions.

And per bug 1763411 comment 11, WebRender folks are interested to take a look and see if it's possible to make particular cases use colorful subpixel antialiasing, and this seems like a case where it'd be nice to do so.

(Clarifying bug title; please let me know if I'm not accurately capturing the spirit of the bug report, i.e. if you were describing something completely different from how I'm interpreting it.)

Here's a screenshot showing what I'm seeing at the top of about:preferences#general, zoomed in so that the method of antialiasing can be clearly seen.

I can see what's happening here, I think the appropriate fix will probably be somewhere in the Firefox frontend code. I can at least explain what's happening so we can work out the right place to fix this.

First, some background:

1. To allow correct subpixel AA, the background must be opaque for correct blending - if WR doesn't find an opaque background for a given content region, it disables subpixel AA.

2. WR cuts the scene in to different slices, depending on the scrolling root of the content - we do this to avoid re-drawing things as you scroll, instead compositing those slices together as they move.

The problem:

In this case, there are some large opaque background rectangles, however all of them are fixed position (they don't scroll as the user scrolls the main content). The scrollable content itself doesn't have a "background" rectangle primitive that moves with the content.

WR splits those in to two different content slices, and it sees the scrollable region as being transparent, since when it draws that to a surface there is no opaque background, thus it disables subpixel AA. The opaque background is only apparent when the compositor combines those content slices together.

The old graphics backend used to do some heroic (but very costly in terms of performance) to make this work with subpixel AA, but we've decided not to for WR, since it's not only very expensive, but that trick also doesn't work when using the system native compositor (such as DirectComposition or CoreAnimation), which we generally want enabled for performance and power usage.

To fix this:

If feasible, the simplest fix is for the about:preferences page to add an additional opaque background color rect that is part of the scrollable region. Once this happens, WR will see the scrollable region as opaque, and enable subpixel AA.

dholbert, does that sound reasonable? And if so, who should we route this to for the suggested change?

Thanks for investigating that! This sounds totally reasonable, yup. RE who-to-route-this-through: it'd probably be a change to https://searchfox.org/mozilla-central/rev/2be8794dd98b299fcfc5ce66e794e8b85ca14510/browser/themes/shared/preferences/preferences.css , and it looks like Gijs is a frequent reviewer of changes there, so he might be able to fix this or approve a suggested-fix.

Based on comment 6, it sounds like the right fix would be to add...

background: var(--in-content-page-background);

...to .pane-container (which is the thing that scrolls).

That fixes some of this, e.g. it makes clickable checkbox-labels paint with subpixel AA, but lots of text (e.g. the "General" and "Startup" headings, disabled checkbox-labels, the "Nightly is currently your default browser" message) are all still drawn with grayscale AA.

At least for disabled checkbox-labels, I can sort-of explain it -- those ones have opacity:0.5 which seems to force grayscale-AA in this context (though it doesn't in other contexts like e.g. data:text/html,<div style="opacity:0.5">Hello)

But for the titles and the default-browser message, I'm not sure why we're using grayscale AA when I give the scrolling element a solid background (or how to avoid that).

Huh, that seems surprising - I can take a look again today / tomorrow and see what the cause of that is.

One feature that might be useful to know about when investigating these kinds of issues is gfx.webrender.debug.picture-caching. When this is enabled, you can see all the slices and tiles that WR is rendering (and what's invalidating etc).

I'll attach an image shortly which explains how to interpret this.

(In reply to Daniel Holbert [:dholbert] from comment #7)

the "Nightly is currently your default browser" message) [is] still drawn with grayscale AA.

For this one, the only way to get colorful AA seems to be by putting a solid background on the label's parent (<hbox id="isDefaultPane">) or grandparent (<stack id="setDefaultPane">). Further ancestors (e.g. the great-grandparent <vbox id="defaultBrowserBox">) don't seem to help here, if I give them a solid background (despite the fact that they're not anywhere close to being the nearest scroller).

the "General" and "Startup" headings

For these ones, they remain grayscale-AA'd even if I add a white background to literally everything by putting * { background: white !important; } at the top of preferences.css (in devtools style editor). So there's something else going on there...

All of these seem to be cases where we're nesting "regular web content" (e.g. <html:h1>, <html:h2>, <stack>-implemented-under-the-hood-using-CSS-grid) inside of XUL. Maybe there's some case where webrender throws up its hands if it escapes from an HTML subtree and runs into XUL content without having yet found a solid-background scrolling ancestor?

The green background is opaque, non-invalidated tiles - you can see that the tile boundaries don't move when you scroll.

However, note that there is a set of yellow tiles that scroll with the content. The yellow indicates alpha tiles, without a detected opaque background. You can also get a sense that there's no background, as the bounds of the tiles follow the content (rather than being large enough to cover the background rect, if it was present).

Red means that WR invalidated that region of the content and had to rasterize that part of the screen.

You'll see as you scroll around that there is an adaptive quadtree used to split / merge tiles to try and reduce rasterization and presentation regions, which can identify if we're drawing too much sometimes.

The main thing to look out for with subpixel is if we're seeing content on yellow (alpha) tiles that is shaped to the content (no background rect). There are other reasons for not drawing subpixel, so that won't always help, but it can be a good starting point.

One possibility related to the XUL - I know that in some (many?) cases Gecko gives up on parts of the scene if they are XUL and falls back to blob rasterization (drawing it as a texture inside Gecko and passing that to WR). These cases will often (always?) end up as grayscale AA. So that might be what's happening here - try enabling gfx.webrender.debug.blob.paint-flashing and see if that correlates with those regions.

Thanks - that sounds possibly-related, but I'm not seeing anything when I enable gfx.webrender.debug.blob.paint-flashing. (I restarted Firefox just in case it mattered, and I tried adding my * { background: white !important; } CSS rule inside preferences.css in devtools, but still no noticeable flashing/etc.)

OK, will take a look. I'm also pondering how we can do a better job (efficiently) in WR of detecting the case where there is a fixed position solid color background with scrolling content that has no background. That's a common enough case that it's probably worth specializing for, and would fix a number of areas we don't currently get subpixel in.

FWIW I would be happy to add a background color to page root or similar if that was sufficient here, but it sounds like it isn't. If we'd need to add explicit "duplicate" backgrounds to multiple containers here that feels a bit code-smelly to me, and like we need a fix on a different layer.

We've seen similar issues in bug 1575743 / bug 1724057 and unfortunately frontend struggled with lack of expertise/tooling to work out what to do there, too.