STR: 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". Expected results: Label with reduced opacity still uses subpixel AA. Actual results: 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: Adapter Description Intel(R) HD Graphics Family Vendor ID 0x8086 Device ID 0x0126 Adapter RAM Unknown Adapter Drivers igdumd64 igd10umd64 igd10umd64 igdumdx32 igd10umd32 igd10umd32 Driver Version 220.127.116.118 Driver Date 9-26-2011 Adapter Description (GPU #2) NVIDIA Quadro 1000M Vendor ID (GPU #2) 0x10de Device ID (GPU #2) 0x0dfa Adapter RAM (GPU #2) 2048 Adapter Drivers (GPU #2) nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Driver Version (GPU #2) 18.104.22.16858 Driver Date (GPU #2) 3-4-2012 Direct2D Enabled true DirectWrite Enabled true (6.1.7601.17789) ClearType Parameters ClearType parameters not found WebGL Renderer Blocked for your graphics card because of unresolved driver issues. GPU Accelerated Windows 1/1 Direct3D 10 AzureBackend direct2d
(Quoting Andrew Hurle [:ahurle] from comment #0) > I *cannot* reproduce this issue on Firefox 14.
Keywords: regression, regressionwindow-wanted
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/36e938e51481 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120522212625 Bad: http://hg.mozilla.org/mozilla-central/rev/aa2b52bd0374 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120523024422 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=36e938e51481&tochange=aa2b52bd0374 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/bbb12d0bcf49 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120521220651 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/abbf642df562 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120521222950 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=bbb12d0bcf49&tochange=abbf642df562 Triggered by: Bug 715768 An I confirmed that it works as expected if I set gfx.content.azure.enabled = false.
Awesome work Alice! Thanks a lot.
Summary: Hardware acceleration causes transparent text in XUL to use grayscale antialiasing instead of subpixel → [Azure] transparent text in XUL uses grayscale antialiasing instead of subpixel
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
Tracking this regression, would be great to get a fix in so we never ship with this.
status-firefox15: --- → affected
status-firefox16: --- → affected
tracking-firefox15: ? → +
tracking-firefox16: ? → +
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: https://hg.mozilla.org/releases/mozilla-beta/rev/5f2f7027b65b
status-firefox15: affected → ---
tracking-firefox15: + → ---
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.
status-firefox16: affected → unaffected
tracking-firefox17: --- → +
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.
Attachment #666480 - Flags: review?(joe)
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.
Attachment #666480 - Flags: review?(joe) → review+
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
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.
Status: RESOLVED → VERIFIED
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.
Attachment #666480 - Flags: approval-mozilla-beta?
Attachment #666480 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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.
You need to log in before you can comment on or make changes to this bug.