Screenshot comparing text rendering with layers.acceleration.force-enabled true (ok) /false (broken)
12.39 KB, image/png
5.26 KB, patch
|Details | Diff | Splinter Review|
3.76 KB, image/png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 Build ID: 20160818050015 Steps to reproduce: 1. Opened gmail Actual results: Observed subpixel AA is broken for gmail's red "Inbox" text Expected results: The text is subpixel antialiased as if the font color was black.
this is actually a regression, it has been reported as bug 833850 and bug 828206, was fixed in the meantime but is now broken again.
When setting layers.acceleration.force-enabled=true, the issue seems to vanish - so it seems to happen only without opengl accelerated rendering.
Created attachment 8783673 [details] Screenshot comparing text rendering with layers.acceleration.force-enabled true (ok) /false (broken)
Does this still happen with nightly if you disable layers acceleration?
Sure, I can reproduce it with Nightly and a clean profile with layer acceleration disabled
I can confirm that this happens on nightly with layers acceleration disabled as well. With Skia content I only get grayscale AA for the Inbox text, vs. subpixel AA for the email headings. That in and of itself wouldn't necessarily be a bug, since some cases may legitimately disable subpixel AA, and the grayscale AA is at least rendered correctly. What is odd is it diverges from what Cairo seems to be doing here. On Cairo content, I get the symptoms as described above for the Inbox text. I suspect this may be a case of subpixel AA being used on a non-opaque layer. I am still investigating to find out what's going on...
Created attachment 8785356 [details] [diff] [review] disable explicit subpixel AA when not permitted in DrawTargetCairo::FillGlyphs The cairo_surface_set_subpixel_antialiasing extension is not honored by image surfaces. So when we disabled Xrender (or with Xrender on with system Cairo), subpixel AA was always being used even in cases where it needed to be disabled like on BGRA surfaces. This fix will work on cairo-ft for both tree and system Cairo, so I opted for it instead of messing with a Cairo-specific change. As ideally we want to reduce dependencies on tree Cairo modifications where possible these days in the hope of one day being able to use system Cairo, this seemed like a better way to go about it.
This was a regression caused by bug 1180942, which landed in 46, where we disabled Xrender for content rendering. The cairo_surface_set_subpixel_antialiasing setting was only used by xlib surfaces, but not by image surfaces. We should uplift fix this once it lands.
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/3c2b69f54e9b disable explicit subpixel AA when not permitted in DrawTargetCairo::FillGlyphs. r=jrmuizel
As far as I understood, your patch will disable subpixel AA for the reported content. However, Google-Chrome is able to render the label with subpixel-antialiasing enabled, please see the screenshot attached.
Created attachment 8785563 [details] google chrome renders the inbox label correctly with subpixel AA
(In reply to Clemens Eisserer from comment #11) > As far as I understood, your patch will disable subpixel AA for the reported > content. > > However, Google-Chrome is able to render the label with > subpixel-antialiasing enabled, please see the screenshot attached. The patch does not disable subpixel AA. Subpixel AA was already disabled higher up, and the backend was not respecting the decision, which caused the problem, since we can't render subpixel AA into a transparent surface. I would encourage you to file the issue that subpixel AA has been disabled for that layer as a new bug, so we can let at least this particular issue be resolved.