Status Update
Comments
bu...@google.com <bu...@google.com> #2
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.
dr...@google.com <dr...@google.com> #3
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
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:
internalMakeGlyph()
.
dr...@google.com <dr...@google.com> #5
Yes, then we get very minor differences to FT, and a more contrasted rendering.
bu...@google.com <bu...@google.com> #6
Ah, sorry, forgot we copy-pasted that code over. If you change false
does that "fix" this?
wa...@chromium.org <wa...@chromium.org> #7
Re
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!).
bu...@google.com <bu...@google.com> #8
No, there is no change in the fact that we don't have per-subpixel alpha.
wa...@chromium.org <wa...@chromium.org> #9
Thanks
Re
The current status: We achieve 60% subpixel antialiasing on Windows lowdpi:
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
, and have just extendedsubpixel raster translation mechanism . We have to disable subpixel antialiasing if the alignment can't be achieved.the algorithm to render surfaces - We tried to implement a
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.background pulling algorithm - 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
for filters that won't cause (obvious) color fringing.enabling subpixel antialiasing
We have always been dreaming of universal subpixel antialiasing to avoid the complexity for determining/achieving it :)
dr...@google.com <dr...@google.com> #10
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.
kj...@google.com <kj...@google.com> #11
(Assigning bug to somebody to get it out of our triage queue)
ap...@google.com <ap...@google.com> #12
Project: skia
Branch: main
Author: Dominik Röttsches <
Link:
[Fontations] Match FreeType antialiasing on unknown pixel geometry
Expand for full commit details
[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>
Files:
- M
gm/fontations_ft_compare.cpp
- M
src/ports/SkTypeface_fontations.cpp
Hash: 13c6a67128538902d1206590fe9e256c54143e35
Date: Mon Feb 17 12:39:55 2025
Description
What steps will reproduce the problem?
In Chrome on Linux, visithttps://rtsh.es/test/blur.html and FontConfig configured to produce requests for subpixel antialiasing or
in
fontconfig_util.cc
.The test page has sample text in Roboto and Inter, on a
will-change:transform
transformed layer, which causes the layer to be composited.What is the expected output? What do you see instead?
Output rendering no less crisp than in FreeType backend.
Analysis:
FreeType Case:
In the FreeType backend, to produce glyph rendering, the code reaches
SkScalerContextFTUtils::generateGlyphImage
with mask format being set toSkMask::kA8_Format
due to thekUnknown_SkPixelGeometry
case inSkScalerContext::MakeRecAndEffects
, then the code proceeds to producing an actual grayscale rendering in:Fontations case:
The equivalent Fontations code path is in Fontations
SkScalerContext_Fontations::generateImage
, which is modelled after the DirectWrite backend. It does the following:This produces a less optimal quality rendering: We're anyway performing a from-path rendering here and intentionally degrading that by setting the
a8LCD
bool to true here, resulting in a more washed-out appereanced, as the RGB antialiasing is slightly wider, and then gets downsampled to grayscale.Proposed Fix
Ignore the
SkScalerContext::kGenA8FromLCD_Flag
flag in the Fontations backend here, and render to antialiased grayscale without thegenA8FromLCD
suboptimal filtering. This might work here, as we do not need to match any RGB antialiased masks coming from any system rasteriser, for example the DirectWrite rasteriser.Would there be any negative side effects with this approach?