Closed Bug 1593216 Opened 5 months ago Closed 5 months ago

Some web content text no longer using subpixel anti-aliasing

Categories

(Core :: Graphics: WebRender, defect)

72 Branch
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 1600472

People

(Reporter: ke5trel, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

STR:

  1. With Basic or WebRender compositor on Ubuntu 19.10.
  2. Go to https://www.reddit.com/r/firefox/
  3. Inspect the text in posts and comments with a magnifying glass.

The text is using grayscale anti-aliasing instead of subpixel.

Regression range:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=26b8000a4954f3f9ee7c5b34f10a73843167fb06&tochange=60e6c61a7f455624b2ef0702d1925f8d8303bb38

Regressed by Bug 1590284.

With recent changes to enable multiple picture caching slices, some pages (in particular, those with a large fixed background image / gradient) will lose subpixel AA with WR enabled. The tradeoff is that we will see significantly better rasterization performance (and battery usage).

I believe this is the same tradeoff that Chrome makes (dropping subpixel AA in these page layouts). Our goal is to ensure we have subpixel AA working in any case where Chrome also manages to do subpixel AA. So, if we come across pages where Chrome gets subpixel AA, but WR doesn't that would be a bug we'd aim to fix.

Some background:

Drawing with subpixel AA on these pages requires either (a) a memory and performance intensive technique where the scrolling content is rasterized twice and mixed during compositing or (b) rasterizing the entire page every time there is a scroll event, due to the fixed background image moving relative to the scrolled content. Notably, (a) is not compatible with OS compositor integration.

By dropping subpixel AA for these page layouts, we can rasterize the content in separate slices and cache these between frames, only compositing them as they scroll at different rates. Further, we can draw these slices directly into OS compositor surfaces (such as DirectComposition and CoreAnimation) for further performance savings and battery wins.

One option we might consider, going forward, is to add a user preference that allows a switch between:

(1) High performance and better battery usage (dropping subpixel AA in these specific cases) or
(2) Higher text rendering quality (enable subpixel AA for these cases, rasterize every frame)

This would allow users that want subpixel AA to enable it, with knowledge of the impact on battery life and performance.

Duplicate of this bug: 1594364

If this is by design (seems maybe after reading the very helpful comment 1), do we want to keep this open? (It came up in regression triage today which is why I'm asking.)

Flags: needinfo?(gwatson)

It does seem reasonable to close this, since:

  • We do expect to lose subpx AA on this specific page (as does Chrome)
  • We have opened (and fixed) https://bugzilla.mozilla.org/show_bug.cgi?id=1594364 for a subpixel regression on a different page.
  • We can open further specific bugs if/when we come across cases where Chrome uses subpx AA but WR doesn't.
Status: NEW → RESOLVED
Closed: 5 months ago
Flags: needinfo?(gwatson)
Resolution: --- → WONTFIX

Let's mark this as duplicate of bug #1600472, as now real work for same issue is going there.

No longer regressed by: 1590284
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 1600472
You need to log in before you can comment on or make changes to this bug.