Closed Bug 1520176 Opened 5 years ago Closed 5 years ago

Bugzilla is no longer using Sub-pixel AA

Categories

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

x86_64
Windows 10
defect

Tracking

()

RESOLVED FIXED
mozilla67
Tracking Status
firefox-esr60 --- unaffected
firefox64 --- disabled
firefox65 --- disabled
firefox66 --- disabled
firefox67 --- fixed

People

(Reporter: alice0775, Assigned: lsalzman, NeedInfo)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached image 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

Attached file about:support

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

Priority: -- → P3

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.

Flags: needinfo?(jmuizelaar)

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.

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.

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.

Assignee: nobody → lsalzman
Status: NEW → ASSIGNED
Attachment #9040187 - Flags: review?(matt.woodrow)
Attachment #9040187 - Flags: review?(matt.woodrow) → review+
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/300c5aac4b2e
use HasAnimationOfTransform() to detect if WR stacking context is animated. r=mattwoodrow
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla67
Depends on: 1524509
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: