1520176 - Bugzilla is no longer using Sub-pixel AA

Status: RESOLVED FIXED

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

Description

[Alice0775 White]

Attachment: screenshot good vs bad

Reproducible: always

Steps to reproduce:

1. open bugzilla bug(not need log in)
   e.g https://bugzilla.mozilla.org/show_bug.cgi?id=1195927

Actual results:
font rendered in gray scale AA

Expected results:
Sub-pixel AA

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=9c2deb188bdf3065b8f871426fc4d640bd3ea6ea&tochange=65789d9edfe6037dfebc431d97892d38a5c7e05a

Regressed by: 65789d9edfe6 Alexis Beingessner — Bug 1435094 - wire up GlyphRasterSpace to nsDisplayTransform. r=kats,mstange

Comment 1

[Alice0775 White]

Attachment: about:support

Comment 2

[Alice0775 White]

(FYI, blurry text in today's nightly66, but this is a different issue. See Bug 1520126.)

Comment 3

[Liz Henry (:lizzard) (relman/hg->git project)]

Happy to take a patch in nightly 67, or potentially, in beta 66 for this.
I'm marking it fix-optional to remove it from weekly regression triage, since it has a priority assigned.

Comment 4

[Lee Salzman [:lsalzman]]

So, this is currently explicit behavior. Bugzilla uses "will-change: transform" to trick Safari into giving better smooth scrooling behavior. And when we detect something may be animated, for example via "will-change: transform", we decide to disable subpixel AA so that things don't suddenly jarringly transition when the transform is actually animated.

So, for this to be a bug, we'd need to decide if we care about use-cases like this where will-change s not actually signaling a transform, and be lazier about determining when to disable subpixel until there is actually a really-real changing transform.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

But really, bugzilla should just remove will-change:transform. It doesn't seem necessary in Safari anymore and if you're not changing the transform you shouldn't be using will-change:transform.

Comment 6

[Lee Salzman [:lsalzman]]

Attachment: use HasAnimationOfTransform() to detect if WR stacking context is animtaed

It seems after discussion with Matt Woodrow that FrameLayerBuilder is rather using nsIFrame::HasAnimationOfTransform() to detect animations instead of ActiveLayerTracker::IsStyleMaybeAnimated(). For now, this switches to use the former so that WR is consistent with FLB's behavior.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/300c5aac4b2e
use HasAnimationOfTransform() to detect if WR stacking context is animated. r=mattwoodrow

Comment 8

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/300c5aac4b2e