1722163 - No subpixel anti-aliasing with WebRender on https://doc.rust-lang.org/stable/std/

Status: UNCONFIRMED

(Core :: Graphics: WebRender, enhancement, P5)

Description

[Paul]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36

Steps to reproduce:

1. Enable WebRender
2. Go to https://doc.rust-lang.org/stable/std/

Actual results:

Almost all the text is rendered without subpixel anti-aliasing.

Expected results:

WebRender should do subpixel anti-aliasing here like it did before (without WebRender).

Comment 1

[Paul]

Also the other bugreport https://bugzilla.mozilla.org/show_bug.cgi?id=1673225 doesn't seem to be related because it mentions "during animations or for stroked text" which isn't the case here.

Comment 2

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

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

Comment 3

[Jeff Muizelaar [:jrmuizel]]

I confirmed that this also shows up on Windows. Chrome does have subpixel AA on this page. Glenn, do you mind taking a quick look at why we're not getting subpixel-aa here?

Comment 4

[Miko Mynttinen]

Attachment: rustdoc.png

Comment 5

[Jeff Muizelaar [:jrmuizel]]

I had a look at the structure of the page here. The sidebar is behind the content, is position:fixed and is in-between the background and the content so it's not unreasonable for us to lose subpixel AA here.

Chrome seems to track this at the item level. If I position one of the headings so that it partially overlaps the fixed sidebar it loses subpixel-aa

Comment 6

[Glenn Watson [:gw]]

I confirmed what you found above. The existing structure of the page means it's not surprising we lose subpixel with the current WR implementation.

As you said, forcing the position of one text element in the main content to overlap results in that text run losing subpixel AA, but the surrounding text runs retain subpixel AA, so it must be doing item level bounding rect overlap tests.

I need to think about this a little bit more, but it seems likely that we can use the recently added sub-slice functionality for non-opaque compositor surfaces to achieve something similar here (that feature has functionality where we check per-item if it overlaps a "prohibited" set of rect(s), and can move the prim to be drawn on an earlier sub-slice if it doesn't overlap that, allowing subpixel AA to be enabled).

In the case of this page layout, this would be a little extra CPU cost to do the overlap tests, but would probably be a performance win overall, as the content layout means that we'd end up not creating a slice / tiles for the page content - it would all end up on the background slice. So this might save compositing time + GPU memory + rendering time overall for cases like this.

Comment 7

[Paul]

Just curious, is there a flag/way to force-enable subpixel aa regardless of the computational cost?

Comment 8

[ValdikSS]

(In reply to Paul from comment #7)

Just curious, is there a flag/way to force-enable subpixel aa regardless of the computational cost?

Try gfx.webrender.quality.force-subpixel-aa-where-possible in about:config

Comment 9

[Paul]

(In reply to ValdikSS from comment #8)

(In reply to Paul from comment #7)

Just curious, is there a flag/way to force-enable subpixel aa regardless of the computational cost?

Try gfx.webrender.quality.force-subpixel-aa-where-possible in about:config

Just tried it, unfortunately it doesn't work on the rust documentation page.

Comment 10

[Paul]

Another data point. Even with the layout fixed (there is no overlap), sub-pixel anti-aliasing is turned off:

Live demo:

https://musing-kepler-408faa.netlify.app/std/index.html