Closed Bug 1594364 Opened 5 years ago Closed 5 years ago

Protonmail text no longer using subpixel anti-aliasing where it does on Chrome

Categories

(Core :: Graphics: WebRender, defect)

72 Branch
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla72
Tracking Status
firefox-esr68 --- unaffected
firefox70 --- unaffected
firefox71 --- unaffected
firefox72 --- fixed

People

(Reporter: ke5trel, Assigned: gw)

References

(Regression)

Details

(Keywords: regression)

Attachments

(2 files)

STR:

  1. With WebRender compositor on Ubuntu 19.10.
  2. Go to https://protonmail.com
  3. Inspect the text with a magnifying glass.

Text is using grayscale anti-aliasing instead of subpixel.

Does not happen with Basic compositor. Works on Chrome.

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

Regressed by Bug 1590284.

Flags: needinfo?(gwatson)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE

This is a specific instance of the problem that we want to understand and perhaps deal with differently than bug 1593216

Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Confirmed - will take this and work out what the differences are.

Assignee: nobody → gwatson
Flags: needinfo?(gwatson)

Interestingly, Chrome decides not to create a compositor surface for the large(ish) fixed position images that show up during scrolling as a parallax effect. I'm not sure exactly what determines that yet - it does create a compositor surface for cases like https://reddit.com/r/rust, disabling subpixel AA in that case.

I prototyped not creating a compositor surface in WR for this case, and found that everything was being invalidated and rasterized every frame. Which led me to investigate and find the root cause - https://phabricator.services.mozilla.com/D52275. With that fix in place, when WR renders the protonmail page as a single compositor layer, the invalidation works as expected, just rasterizing the fixed position elements as you scroll past it. Once that lands, it will be much more feasible / efficient to not create compositor layers for fixed position elements in cases like this.

Instead of creating a picture caching slice for any content that
is fixed position, also check if the clip(s) for the cluster are
fixed position or anchored to the scroll root.

This prevents WR creating slices for parallax style effects. There's
not much point in doing this anyway, since those slices will invalidate
due to the spatial node of the clip changing during scrolling. This
also allows subpixel AA to be enabled in more situations.

Pushed by gwatson@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/03ab38bbbd2e Support subpx AA with picture caching in more cases. r=kvark
Status: REOPENED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla72
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: