Firefox add-ons manager kills sub-pixel anti-aliasing for all text, chrome and web

VERIFIED FIXED

Status

()

Core
Layout
VERIFIED FIXED
7 years ago
a year ago

People

(Reporter: asa, Assigned: tnikkel)

Tracking

({regression})

Trunk
x86
Windows 7
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker][radiusclip][fx4-fixed-bugday])

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 491330 [details]
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

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
Assignee: nobody → roc
blocking2.0: --- → ?
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.
Assignee: roc → tnikkel
blocking2.0: ? → betaN+
Component: Graphics → Layout
QA Contact: thebes → layout
(Assignee)

Comment 4

7 years ago
(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)?
(Assignee)

Comment 6

7 years ago
cairo 1.10 doesn't seem to change the AA on Linux at least.
(Assignee)

Comment 7

7 years ago
My patch for doing the PushGroup/PopGroup thing make my testcase for bug 579488 about 10% slower.
(Assignee)

Comment 9

7 years ago
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.
(Assignee)

Comment 10

7 years ago
It seems to make using the scrolling benchmark bookmarklet on the testcase in bug 611963 about 20% faster though.
(Assignee)

Comment 11

7 years ago
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%.
(Assignee)

Comment 12

7 years ago
Jeff told me he had some ideas for how to do the whole rounded rect clip thing better.
Keywords: regression
(Assignee)

Updated

7 years ago
Blocks: 622064
Whiteboard: [hard blocker]
Whiteboard: [hard blocker] → [hardblocker]
Whiteboard: [hardblocker] → [hardblocker][radiusclip]
(Assignee)

Comment 13

7 years ago
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.
Depends on: 628745
(Reporter)

Comment 18

7 years ago
This is now fixed for me on Windows 7.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110204 Firefox/4.0b12pre
Status: RESOLVED → VERIFIED
Whiteboard: [hardblocker][radiusclip] → [hardblocker][radiusclip][fx4-fixed-bugday]
You need to log in before you can comment on or make changes to this bug.