None of the text in the Firefox add-ons manager, including all the local UI text, as well as iframed remote web content, is sub-pixel anti-aliased on my system. Screenshot attached showing the Get Add-ons remote content displayed in the Add-ons Manager without sub-pixel aa, and displayed directly in the browser with sub-pixel aa. (sorry for the shotgun cc. not sure who this really belongs to.) Other "chrome" pages like about:config and about:support are not affected. They show sub-pixel aa text just fine. General web pages are not affected. They also show sub-pixel aa text just fine. Firefox's primary UI chrome is also not affected. Tested on today's mozilla-central windows installer build on Windows 7 Professional. I believe that hardware accelerated graphics is automatically disabled for this machine. Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family Vendor ID: 8086 Device ID: 2a42 Adapter RAM: Unknown Adapter Drivers: igdumdx32 igd10umd32 Driver Version: 8.15.10.2182 Driver Date: 7-19-2010 Direct2D Enabled: Blocked on your graphics driver. Try updating your graphics driver to version 8.15.10.2202 or newer. DirectWrite Enabled: false GPU Accelerated Windows: 0/1

The addons manager has rounded corners on its scrollbox so we have to clip to the rounded rectangle. This forces all drawing to go through the "clip with mask" path. That forces _cairo_win32_surface_show_glyphs to fall back, so we end up rendering all our text by painting to a temporary RGBA surface and then blitting that out through the mask. Of course, this loses component alpha. (It's also ultra slow.) Implementing clip regions by doing a pushgroup followed by final mask clip on popgroup would fix this. Timothy, should we take your patches for that? Another option would be to not try to antialias the rounded-rect clipping. Another option would be to do some analysis so that display items which do not intersect the boundary of the clip region (or at least the antialiased part of it) are not actually clipped to the region.

Fwiw, I'm pretty sure we have an existing bug on this somewhere.... should dup it forward.

(In reply to comment #1) > Implementing clip regions by doing a pushgroup followed by final mask clip on > popgroup would fix this. Timothy, should we take your patches for that? I think we should take this option. We'd use PushGroupAndCopyBackground.

(In reply to comment #1) > The addons manager has rounded corners on its scrollbox so we have to clip to > the rounded rectangle. This forces all drawing to go through the "clip with > mask" path. That forces _cairo_win32_surface_show_glyphs to fall back, so we > end up rendering all our text by painting to a temporary RGBA surface and then > blitting that out through the mask. Of course, this loses component alpha. > (It's also ultra slow.) Is this still true with cairo 1.10 (bug 562746)?

I don't know.

cairo 1.10 doesn't seem to change the AA on Linux at least.

My patch for doing the PushGroup/PopGroup thing make my testcase for bug 579488 about 10% slower.

Any idea why?

Just speculating here, but in a relatively simple testcase where most of the painting is done by filling large rects and almost all pixels are painted only once the PushGroup/PopGroup mostly just adds overhead in the form of a new surface. When we pop the group and paint we still have to do the slow mask clipping for every pixel, just like we would if we were filling the rects directly to the base surface. But I'm not a cairo expert.

It seems to make using the scrolling benchmark bookmarklet on the testcase in bug 611963 about 20% faster though.

cairo-1.10 speeds up bug 579488 significantly. But the pushgroup patch on top of cario-1.10 makes the hit we take go up to 15-25%.

Jeff told me he had some ideas for how to do the whole rounded rect clip thing better.

My patch for doing the PushGroup/PopGroup thing fails some of our more complex border radius reftests. The failures are not noticeable to my eye (even after reftest-analyzer points them out) and they are a few pixels per test. Probably just an antialiasing or rounding difference. How should we deal with these failures?

(In reply to comment #13) > My patch for doing the PushGroup/PopGroup thing fails some of our more complex > border radius reftests. The failures are not noticeable to my eye (even after > reftest-analyzer points them out) and they are a few pixels per test. Probably > just an antialiasing or rounding difference. > > How should we deal with these failures? In the past we've disabled things. Ideally we'd do 'fuzzy' matches.

There are even patches for one type of fuzzy matching in bug 580786.

That said, we could also mask out pixels or mark things failing.

Please retest now that bug 628745 has been fixed.

This is now fixed for me on Windows 7.

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre