Closed Bug 1055634 Opened 6 years ago Closed 5 years ago

Propagate font smoothing background colors to layers

Categories

(Core :: Graphics: Layers, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36

People

(Reporter: mstange, Assigned: mstange)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
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.
Assignee: nobody → mstange
Status: NEW → ASSIGNED
Attachment #8503180 - Flags: review?(matt.woodrow)
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?
Attachment #8503183 - Flags: review?(smichaud) → review+
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.
Attachment #8503180 - Flags: review?(matt.woodrow)
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?
Attachment #8503180 - Attachment is obsolete: true
Attachment #8505743 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/6cadeeb02a0c
https://hg.mozilla.org/mozilla-central/rev/78cefaa12bd2
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Markus, what are the odds of uplifting this to 35 or 34? :-)
Flags: needinfo?(mstange)
Shouldn't be a problem, I think. I'll check how much work it is to make the patches apply.
Flags: needinfo?(mstange)
You need to log in before you can comment on or make changes to this bug.