1. Open about:preferences
2. Go to Advanced > General tab
3. Inspect the "Use hardware acceleration when available" label with DOM inspector. Note that the label is currently using subpixel AA.
4. Add a style attribute to the label with value "opacity: 0.99".
Label with reduced opacity still uses subpixel AA.
Label with reduced opacity changes to grayscale AA.
If you uncheck the HWA checkbox after step 4, the label will switch to desired subpixel AA (and will remain that way even if you restart Nightly and repeat steps 1-4).
This affects the patch in bug 774118. The text inside a span with opacity < 1 is using grayscale antialiasing instead of subpixel. If I disable hardware acceleration, the transparent text correctly uses subpixel AA. This also seems to occur on other XUL elements when their opacity is lowered, but web pages are unaffected AFAICT. You can see the grayscale AA in this screenshot on Windows 7 on the text "Customize Firefox": https://bugzilla.mozilla.org/attachment.cgi?id=644095
The problem isn't affecting XP or Ubuntu (in VMs). It looks like OSX isn't using subpixel AA regardless of the "LCD font smoothing" setting under System Preferences > General, so I can't say much about it.
I *cannot* reproduce this issue on Firefox 14.
Possibly related to bug 379786 or bug 582223?
about:support Graphics Section, HWA enabled:
Intel(R) HD Graphics Family
igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32
Adapter Description (GPU #2)
NVIDIA Quadro 1000M
Vendor ID (GPU #2)
Device ID (GPU #2)
Adapter RAM (GPU #2)
Adapter Drivers (GPU #2)
Driver Version (GPU #2)
Driver Date (GPU #2)
ClearType parameters not found
Blocked for your graphics card because of unresolved driver issues.
GPU Accelerated Windows
1/1 Direct3D 10
(Quoting Andrew Hurle [:ahurle] from comment #0)
> I *cannot* reproduce this issue on Firefox 14.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120522212625
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120523024422
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120521220651
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120521222950
Triggered by: Bug 715768
An I confirmed that it works as expected if I set gfx.content.azure.enabled = false.
Created attachment 645669 [details]
Awesome work Alice! Thanks a lot.
Tracking this regression, would be great to get a fix in so we never ship with this.
Bas, do you have an ETA for this fix? It's blocking bug 774118 which is an intern project and Andrew's internship ends next week. Thanks.
We should switch off Azure content for now. I'll put up a patch elsewhere.
Switched off Azure content:
Hi Roc, question here, although I'm quite puzzled by Azure making a difference here in the first place .. A span with a non 1.0 opacity -should- get grayscale AA, right?
(In reply to Bas Schouten (:bas) from comment #9)
> Hi Roc, question here, although I'm quite puzzled by Azure making a
> difference here in the first place .. A span with a non 1.0 opacity -should-
> get grayscale AA, right?
Actually, I guess that's not entirely true if -just- the text is partially transparent.
I don't think it's true at all :-). With HWA on, we should be able to get subpixel AA everywhere (except over the glass parts of the window).
Azure support backed out of FF16 in bug 769993.
What's the plan here for 17? Are we backing out again?
Because we need to fix the bug instead of keep backing out of Azure content.
Sure. Is it going to be fixed in Firefox 17? How about bug 769993?
Yes, hopefully Bas can fix these bugs.
Created attachment 666480 [details] [diff] [review]
When copying in background use CONTENT_COLOR
This makes behavior here analogous to the Cairo version of this function. Pushing an opaque group when we know we're going to copy in an opaque background anyway.
I'm assuming this is a minimal patch that doesn't quite implement comment 11. Will the latter be spun off to a separate bug?
(In reply to Dão Gottwald [:dao] from comment #20)
> I'm assuming this is a minimal patch that doesn't quite implement comment
> 11. Will the latter be spun off to a separate bug?
No, it should more or less implement it properly. Although there might still be some cases where BasicLayers ruins it for us.
Created attachment 668015 [details]
Alpha issue in Nautipolis caused by the patch of this bug?
Is this rendering issue caused by this patch?
I will await the next nightly and retest, because it could also have been caused by 778367 and the correspondig fix for that:
Bug 797314 - Strange artifacts on some sites
Can someone verify this on trunk and nominate for uplift to Beta if the issue is verified fixed? We'll want this in tomorrow's Beta go to build so please nominate as soon as possible.
I will need far more detailed steps to reproduce which assumes complete unfamiliarity with DOM Inspector as I'm having a hard time reproducing this. Thanks.
Verified fixed with the latest nightly on Win7 and AzureContentBackend = direct2d.
Lukas, give that we missed Beta 2, did we want to try to get this in for Beta 3?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #27)
> Lukas, give that we missed Beta 2, did we want to try to get this in for
> Beta 3?
Yes, absolutely. Please nominate for uplift now that this is verified - we'll need this to land by EOD PT tomorrow (Monday)
Comment on attachment 666480 [details] [diff] [review]
When copying in background use CONTENT_COLOR
Requesting approval for Beta based on comment 28.
This patch has never been tested without bug 778367 and the subsequent patches in Bug 797314, Bug 797231 and Bug 797797. I think the safe option is to push this along with those patches in the next beta to ensure we actually have had Aurora test coverage.
The risk of breaking beta otherwise appears too high.
Thanks Bas, we'll hold off on all your Azure bugs and go for Beta 4 with all of them
Ok the patches in bug 778367 and the subsequent patches in Bug 797314, Bug 797231 and Bug 797797 have all been approved. Please get this (and those patches) in today so that we're set for Beta 4 and we can take a look this week for any regressions that would block shipping Azure in 17.