1724057 - No subpixel anti-aliasing in tab bar, address bar, sidebar, bookmark bar with WebRender

Status: NEW

(Core :: Graphics: WebRender, defect)

Description

[ValdikSS]

User Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Firefox 90.0.2 on Fedora Linux 34 does not have subpixel anti-aliasing in tab bar, address bar, sidebar, bookmark bar with default settings.
The website content has anti-aliasing.

Actual results:

This bug seems to be in WebRender. If I disable WebRender (gfx.webrender.force-disabled=true) and restart the browser, sidebar, tab bar and address bar will have subpixel AA again.

Expected results:

All elements should have subpixel AA with WebRender, just as it is without.

Comment 1

[ValdikSS]

Attachment: Where exactly subpixel anti-aliasing is missing

This is a screenshot with a fresh Firefox profile with default settings, with WebRender.
RED means only grayscale anti-aliasing
GREEN means proper subpixel anti-aliasing.

Comment 2

[ValdikSS]

Attachment: Bookmarks sidebar with no subpixel AA

Bookmarks sidebar with WebRender, no subpixel AA

Comment 3

[ValdikSS]

Attachment: No WebRender, proper subpixel AA everywhere

Now if I disable WebRender (gfx.webrender.force-disabled=true) and restart the browser, every text displayed on the screen has subpixel anti-aliasing.

Comment 4

[ValdikSS]

Attachment: about:support with WebRender enabled and disabled

Additional information:

Linux Fedora 34, KDE Plasma 5, Lenovo ThinkPad X220 laptop with Intel HD 3000 graphics, X11.
Firefox 90.0.2 from official Fedora repository.

Attached file contains about:support information when WebRender enabled and when disabled.

Comment 5

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 6

[:Gijs (he/him)]

Passing this to graphics for a first pass.

Comment 7

[Sotaro Ikeda [:sotaro]]

:gw, can you comment to the bug?

Comment 8

[Glenn Watson [:gw]]

There's a number of reasons we sometimes don't get subpixel AA where non-WR did (sometimes simple bugs, sometimes a known issue requiring some refactoring to fix, sometimes a deliberate choice to enable optimizations / integration with the system compositor where it's not feasible).

I'll need to investigate each of these cases to see which of the above they fall in to.

I suspect this might be one of the easier cases to fix (we may not be calculating an appropriate opaque background region rect if the picture cache slice background has a rounded rect clip on it, which we can handle easily enough if that's the case).

Comment 9

[Glenn Watson [:gw]]

I was able to get a WR capture of the issue with the megabar dropdown open.

The issue is what I suspected - that we don't find a valid (by the current conservative WR definition) background rect that is opaque to enable subpixel AA on that surface.

I hacked out the check for a rounded-rect clip to see if that was the problem. It improves this case, but doesn't fix it. We end up finding a partial opaque background rect which allows subpixel AA on some of the text, but not all.

This still needs further investigation - we should be able to do a better job in WR of finding and opaque background rect for this case, I think, which would enable subpixel AA on the entire surface. Another option is to try and change the front-end UI to have a complete opaque background rect in the display list here, but I don't think that should be necessary.

Comment 10

[ValdikSS]

This also applies to Firefox 91 on Windows. Not only Linux.

Comment 11

[ValdikSS]

The issue present in Firefox 93.
The issue also applies to Thunderbird 91 (https://bugzilla.mozilla.org/show_bug.cgi?id=1732583).

Comment 13

[ValdikSS]

Darkspirit, bug 1732583 is for Thunderbird. This bug is for Firefox.

Comment 14

[ValdikSS]

Wayne Mery, seems I've accidentally removed the depending bug bug can't apply it again.

Comment 15

[Darkspirit]

"Product: Core" affects Firefox and Thunderbird.

Comment 16

[:Gijs (he/him)]

Please leave the "version" field set to the version with which the bug was originally reported. We can track future/other affected versions using the status flags (which are already set for this bug anyway).

Comment 17

[ValdikSS]

Sometimes subpixel anti-aliasing is not used on the websites as well.
For example, I've just spotted it on this page: https://qna.habr.com/q/1106580#comment_2967552
But after refreshing the page subpixel anti-aliasing is usually applies again.
Seen that at least twice on different websites.

Comment 18

[ValdikSS]

Attachment: Screenshot_20220127_122131_habr-fs8.png

Comment 19

[:Gijs (he/him)]

(In reply to ValdikSS from comment #17)

Sometimes subpixel anti-aliasing is not used on the websites as well.
For example, I've just spotted it on this page: https://qna.habr.com/q/1106580#comment_2967552
But after refreshing the page subpixel anti-aliasing is usually applies again.
Seen that at least twice on different websites.

Please file a separate bug for this, the fix is likely going to need to be different.

Comment 20

[ValdikSS]

Firefox 103.0.2.
Everything is the same (no subpixel anti-aliasing in many places), except now the active tab text does have subpixel anti-aliasing.

Comment 21

[Wayne Mery (:wsmwk)]

(In reply to Glenn Watson [:gw] from comment #9)

I was able to get a WR capture of the issue with the megabar dropdown open.

The issue is what I suspected - that we don't find a valid (by the current conservative WR definition) background rect that is opaque to enable subpixel AA on that surface.

I hacked out the check for a rounded-rect clip to see if that was the problem. It improves this case, but doesn't fix it. We end up finding a partial opaque background rect which allows subpixel AA on some of the text, but not all.

This still needs further investigation - we should be able to do a better job in WR of finding and opaque background rect for this case, I think, which would enable subpixel AA on the entire surface.

Is that investigation happening in bug 1770816? Or a different bug?

Comment 22

[Glenn Watson [:gw]]

I'm not actively working on it right now. I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items. Some of the other cases are related to the WR issue mentioned above.

Comment 23

[ValdikSS]

Attachment: Windows 10, Firefox 107.0

Windows 10, Firefox 107.0.

Comment 24

[ValdikSS]

Attachment: firefox107_win10_1.png

Zoomed-in part without subpixel anti-aliasing, #1

Comment 25

[ValdikSS]

Attachment: firefox107_win10_2.png

Zoomed-in part without subpixel anti-aliasing, #2

Comment 26

[ValdikSS]

Attachment: firefox-antialiasing-2022-12-05_02.34.37.mp4

Firefox 108.0 b9 (downloaded from Mozilla), Fedora Linux 35:

• Pressing on the address bar disables subpixel anti-aliasing for the text in address bar
• Drop-down menu in the address bar does not have subpixel anti-aliasing
• Bookmarks in bookmark bar are constantly changing between subpixel anti-aliasing and grayscale upon hovering

Comment 27

[ValdikSS]

Attachment: Issue in Thunderbird 102.5.0

Issue in Thunderbird 102.5.0

Comment 28

[Gregory Pappas [:gregp]]

Is it possible that bug 1820534 fixed this?

I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items

Comment 29

[Emilio Cobos Álvarez (:emilio)]

Probably not the XUL trees, no.

Comment 30

[ValdikSS]

As of Firefox 113.0, most of the issues mentioned in comment 1 and 2 (on the screenshots) still apply.
The only thing which is fixed is subpixel anti-aliasing on the tab title, but only when it's not overflowing the tab button length.

No subpixel anti-aliasing for:

• Tab titles which overflow tab button length
• Text inside address bar when the bar was clicked (and recent website menu opened)
• Text of recent website menu items
• Bookmarks sidebar

Comment 31

[ValdikSS]

(In reply to Gregory Pappas [:gregp] from comment #28)

Is it possible that bug 1820534 fixed this?

I did find that some of the cases are caused by XUL views which are blob rasterized, these cases will likely need to converted to use WR display items

As far as I understand, this change is shipped in 113.0. If so — not fixed.

Comment 33

[ValdikSS]

Firefox 118.0 — no changes.