Skia

It is unfortunate that Skia's FreeType port doesn't respect the kGenA8FromLCD_Flag. I think there are a few bugs open about that (going in and out of layers changing the rendering too much) but actually fixing it has been considered too big of a change (at least in the past, not sure about this with current tooling).

I suppose the request here is to make Fontations be broken in the same way for compatibility? The issue of course being that SkScalerContext::internalMakeGlyph does currently respect kGenA8FromLCD_Flag and that should not be broken, but is the current path that Skia's Fontations port is using.

I guess the alternative fix would be for Chromium to not produce kUnknown_SkPixelGeometry or in other words, leave RGB antialiasing intact when promoting to compositing layers. Then we could leave the rendering to be downsampled from LCD16/rgb antialiasing and this issue would be less pronounced or appear less often. Xianzhu, can you comment on how close we are to that? I remember you had plans for deactivating subpixel antialiasing less often? In the content of Chromium issue 375219950, we do see scrolling layers be promoted to compositing it seems, with disabling subpixel antialiasing. I am not sure, I am capturing this in an identical way in my derived test content https://rtsh.es/test/blur.html but this seems to the be the core of the issue.

The issue of course being that SkScalerContext::internalMakeGlyph does currently respect kGenA8FromLCD_Flag and that should not be broken, but is the current path that Skia's Fontations port is using.

Can you elaborate? How do we reach internalMakeGlyph() for this situation? I think we moved away from relying on internalMakeGlyph() when we fit in COLRv1. For ignoring the a8FromLC flag and for this change, I was proposing to make changes here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/src/ports/SkTypeface_fontations.cpp;l=685?q=typeface_fontations%20a8LCD to possibly ignore the flag, not touching internalMakeGlyph().

Just to be sure, if you hard code a8LCD to false does that "fix" this?

Yes, then we get very minor differences to FT, and a more contrasted rendering.

Ah, sorry, forgot we copy-pasted that code over. If you change that a8LCD to false does that "fix" this?

Re comment#3:

Chromium to not produce kUnknown_SkPixelGeometry

Does that mean Chromium can always assume that subpixel antialiasing is available? That would be a great simplification! We have been using kUnknown_SkPixelGeometry for composited layers with non-opaque backgrounds because Skia subpixel antialiasing required opaque background for subpixel antialiasing. If we didn't send kUnknown_SkPixelGeometry in the case, skia would create a fake opaque background which is black before drawing the subpixel antialised pixels, which would produce very ugly rendering (every subpixel antialiased pixels are black!).

No, there is no change in the fact that we don't have per-subpixel alpha.

Thanks bu...@google.com for confirming.

Re comment#3 about deactivating subpixel antialiasing less often: That's always a goal, but we can never achieve 100% as long as an opaque background is required.

The current status: We achieve 60% subpixel antialiasing on Windows lowdpi: UMA.

tl;dr: More details:

• On Windows and Linux when the display is lowdpi, we try not to composite if the composited layer would have a non-opaque background.
• We always respect explicit compositing triggers like will-change: transform, and some effects (e.g. backdrop-filter) requires compositing.
• We enable subpixel antialiasing if we know that a composited layer has an opaque background (and other conditions).
• We disable subpixel antialiasing for some compositing reasons (e.g. will-change: transform, transform animation) because we can't assume the alignment between raster pixels and screen pixels during the lifetime of the layer and/or animation and we don't want to reraster when the alignment changes.
• For a layer with non-integral screen transform, we try to align raster pixels and screen pixels with a subpixel raster translation mechanism, and have just extended the algorithm to render surfaces. We have to disable subpixel antialiasing if the alignment can't be achieved.
• We tried to implement a background pulling algorithm to pull the opaque background from the underlying layer into a composited layer, but haven't succeeded due to complexity, low priority, negative performance impact and unproved benefit.
• We disable subpixel antialiasing when the colors of antialised pixels can be changed e.g. by a filter, a backdrop-filter or a blend mode to avoid color fringing. I'm working on enabling subpixel antialiasing for filters that won't cause (obvious) color fringing.

We have always been dreaming of universal subpixel antialiasing to avoid the complexity for determining/achieving it :)

Attaching results with proposed fix, for fixed result, see a8FromLcdFalse.png which visibly reduces the pixel differences on a surface with simulated unknown pixel geometry.

(Assigning bug to somebody to get it out of our triage queue)

Project: skia
Branch: main
Author: Dominik Röttsches <drott@chromium.org>
Link:      https://skia-review.googlesource.com/952636

[Fontations] Match FreeType antialiasing on unknown pixel geometry

[Fontations] Match FreeType antialiasing on unknown pixel geometry 
 
Initially the Fontations backend was modelled to match the DirectWrite 
implementation in that on unknown pixel geometries (such as a layer 
subject to transforms or compositing in Chrome) it would produce a 
grayscale antialiasing computed from subpixel RGB antialiasing. 
 
When comparing Fontation and FreeType, this would however mean a 
regression in sharpness as the FreeType backend does not adhere to the 
kGenA8FromLCD_Flag flag and produces an actual grayscale antialiasing 
that is distributed less widely. 
 
Move the Fontations backend to match this behavior by ignoring the 
kGenA8FromLCD_Flag flag. Add a mode for the fontationt_ft_compare* set 
of tests to cover this behavior. 
 
Fixed: skia:396360753 
Cq-Include-Trybots: luci.skia.skia.primary:Build-Debian10-Clang-x86_64-Debug-Fontations,Build-Mac-Clang-x86_64-Debug-Fontations,Test-Debian10-Clang-GCE-CPU-AVX2-x86_64-Debug-All-NativeFonts_Fontations,Test-Mac12-Clang-MacBookPro16.2-CPU-AppleIntel-x86_64-Debug-All-NativeFonts_Fontations,Test-Mac14-Clang-MacMini8.1-CPU-AVX2-x86_64-Debug-All-NativeFonts_Fontations 
Change-Id: Ic53e920148ce10c35caca53d45ffdce57576203a 
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/952636 
Reviewed-by: Ben Wagner <bungeman@google.com> 
Commit-Queue: Dominik Röttsches <drott@google.com> 
Reviewed-by: Dominik Röttsches <drott@google.com>