1734343 - The text in the sidebar tree is displayed as grayscale AA instead of subpixel AA.

Status: NEW

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

Description

[Alice0775 White]

Since WebRender is the default

Steps to reproduce:

1. Open Sidebar

Actual Results:
The text in the sidebar tree is displayed as grayscale AA instead of subpixel AA.

Expected Results:
Should be subpixel AA.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Is this a recent regression? Or just caused by the fact that we force WebRender on now?

Comment 2

[Alice0775 White]

Not a recent regression.
Even if in Firefox 68, the issue appears if WebRender is enabled.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 6

[Dennis Schubert [:denschub]]

Putting this on the list for the next WebCompat triage meeting. We have received a report on webcompat.com about Discord, where this rendering difference makes CJK characters harder to read. The reporter in that report has provided a lot of additional detail, including references to a popular fallback font as an alternative to what Microsoft is shipping per default.

If this is making text harder to read for a lot of people, P3/S4 probably isn't appropriate here.

Comment 7

[Ksenia Berezina [:ksenia]]

Setting this as P2 as there may be a lot of sites affected by this.

Hi Jonathan, wonder if you have thoughts on this? There is some analysis in the webcompat report https://github.com/webcompat/web-bugs/issues/104574 with more details.

Comment 8

[Wayne Mery (:wsmwk)]

(In reply to Ksenia Berezina [:ksenia] from comment #7)

Setting this as P2 as there may be a lot of sites affected by this.

Hi Jonathan, wonder if you have thoughts on this? There is some analysis in the webcompat report https://github.com/webcompat/web-bugs/issues/104574 with more details.

lsalzman, jfk suggests you might know better

Comment 9

[Lee Salzman [:lsalzman]]

Glenn, ideas?

Comment 10

[Glenn Watson [:gw]]

This is because the sidebar hits a fallback path in Gecko and gets drawn as a blob image, which doesn't support subpixel AA (as far as I know).

The correct solution to this is to change Gecko to not hit the fallback path here - I'm not sure what's involved in that or how much work it is. Perhaps Jeff might know. Also including Bob, as a note to discuss who might be able to work on this.

Comment 11

[Bob Hood [:bhood]]

Pulling in Nical for any insights, since he has worked on Blob images and is also currently looking into AA.

Comment 12

[Nicolas Silva [:nical]]

Two orthogonal things here, let's look at the side bar first.

Without digging too much, it looks like the side bar mostly uses rather simple primitives already supported by webrender. A quick dump of the used items show a lot of PushClipRect, PopClip, Fill, FillRect, FillGlyphs and SetTransform.
The main missing primitive is Fill with paths.

We could:

• Reimplement nsDisplayTreeBody on top of the WebRender API instead of Moz2D (would need to figure out where the Fill primitives come from and how to render them).
• Reimplement the side bar using CSS instead of whatever custom thing is currently using nsDisplayTreeBody (xul I guess).

Either would work although it would be good to know if we have plans to move more of the UI away from xul before embarking in re-doing nsDisplayTreeBody and other custom primitives with webrender display items (since they don't affect web content).

Probably more a matter of how important it is to have subpx AA in the side bar and who is available to do the work.

There is also possibly implementing sub-px AA text in blob images. That would, I think, only work when we are guaranteed to have an opaque background in the blob image. It's probably the case here but the motivation to invest resource in the blob image code tends to be rather low because we'd like to phase that code path out over time and it does not affect the majority of web content.

Setting this as P2 as there may be a lot of sites affected by this.

I think that multiple issues are conflated in this bug.

The case of the side bar is special because it is drawn using different code paths from actual websites. Fixing the side bar is independent form the long tail of cases where parts of websites don't have sub-px aa, most of which is not related to blob images.

I suggest removing the webcompat priority from this bug and filing website-specific bugs about missing sub-px AA as the work will be different.
I looked at discord and the text does not appear to be drawn via blob images.

Comment 13

[Calin Tanase]

The issue is still reproducible based on the webcompat report: https://github.com/webcompat/web-bugs/issues/104574

Environment:
Operating system: Windows 10
Browser tested: Firefox Nightly 128.0a1 (2024-05-29) / Firefox Release 126 / Edge 125.0.2535.67

Note: Not reproducible on Edge