1055634 - Propagate font smoothing background colors to layers

Status: RESOLVED FIXED

(Core :: Graphics: Layers, defect)

Description

[Markus Stange [:mstange]]

On Desktop, when rendering text into a transparent layer, we usually promote that layer to a component alpha layer, so that we can composite the layer with roughly correct results onto an opaque background layer later on.

However, this only works if there is an opaque backdrop to composite our layer onto. If the window itself is transparent, none of this is going to work, we don't create component alpha layers, and we don't get subpixel anti-aliased text rendering.

For the vibrancy effect on 10.10 we need to draw the contents of vibrant widgets (sidebars and menus) directly on transparency. However, the colors of the vibrancy effect are somewhat constrained: Each type of vibrancy has a certain tint, e.g. light gray, dark gray, or dark blue, and the actual colors don't differ from this tint by a large amount. This lets us draw text with a certain "expected" background color, in such a way that when the surface that contains the text is composited onto that expected color, the result will look completely correct, and when the actual background color is slightly different from the expected color, the result won't be too far off. CoreGraphics gives us an API to specify the expected background color for text rendering, see bug 1055622.

Using that API we can have transparent layers with text in transparent parts of the layer that still has correct-looking subpixel anti-aliasing.

This bug is about getting expected colors from themed widgets, propagating them to transparent layers that can't use component alpha because they're on top of transparent window areas, and calling the Moz2D API from bug 1055622 at the right times.

Comment 1

[Markus Stange [:mstange]]

Attachment: part 1: propagate the color from nsITheme to DrawTarget

This is as simple as I could make it and it skips some corner cases. The way this usually works is: A vibrant -moz-appearance values results in two display items: nsDisplayClearBackground and nsDisplayThemedBackground. The first one builds an active color layer, and the second one is a regular PaintedLayer display item that triggers the creation of a new PaintedLayer on top of the ColorLayer. Since this is the first display item in that layer, we can get the font smoothing background color for the layer from that item.
Regular web content is inside a ContainerLayer anyways, and we don't propagate font smoothing background colors through them, so it's not affected.

Comment 2

[Markus Stange [:mstange]]

Attachment: part 2: propagate the color from NSVisualEffectView to nsITheme

Comment 3

[Steven Michaud [:smichaud] (Retired)]

Comment on attachment 8503183 [details] [diff] [review]
part 2: propagate the color from NSVisualEffectView to nsITheme

This looks fine to me, but I have a suggestion and a question.

+@interface NSView(FontSmoothingBackgroundColor)
+- (NSColor*)fontSmoothingBackgroundColor;
+@end

You should probably add a comment saying that this is an undocumented method present on OS X 10.9 and up.

+- (NSColor*)vibrancyFontSmoothingBackgroundColorForWidgetType:(uint8_t)aWidgetType
+{
+  if (!mGeckoChild) {
+    return [NSColor clearColor];
+  }
+ ...

Are you sure you want to return [NSColor clearColor] rather than NULL when mGeckoChild is NULL?

Comment 4

[Markus Stange [:mstange]]

Comment on attachment 8503180 [details] [diff] [review]
part 1: propagate the color from nsITheme to DrawTarget

This will need to change due to the Moz2D API changes in bug 1055622.

Comment 5

[Markus Stange [:mstange]]

Attachment: part 1, v2: propagate the color from nsITheme to FillGlyphs

Getting the color from FrameLayerBuilder to the FillGlyphs call is really hard. The whole chain now looks like this:

nsITheme::WidgetProvidesFontSmoothingBackgroundColor -> nsDisplayItem -> PaintedLayerData -> PaintedDisplayItemLayerUserData -> gfxContext -> TextRunDrawParams -> GlyphRenderingOptions -> DrawTargetCG::FillGlyphs

Especially gfxContext shouldn't really be in there. Do you have an idea for a better solution?

Comment 6

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6cadeeb02a0c

Comment 7

[Markus Stange [:mstange]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/78cefaa12bd2

Comment 8

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/6cadeeb02a0c
https://hg.mozilla.org/mozilla-central/rev/78cefaa12bd2

Comment 9

[:Gijs (he/him)]

Markus, what are the odds of uplifting this to 35 or 34? :-)

Comment 10

[Markus Stange [:mstange]]

Shouldn't be a problem, I think. I'll check how much work it is to make the patches apply.