582223 - Retained layers and fixed background forces grayscale rather than subpixel antialiasing

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Anthony Ricaud (:rik)]

Attachment: Firefox 4 screenshot

See attached screenshots.

In Firefox 4, it looks worse, kind of JPEG artifacts.

Comment 1

[Anthony Ricaud (:rik)]

Attachment: Firefox 3.6 screenshot

Comment 2

[Boris Zbarsky [:bzbarsky]]

Anthony, I'm not seeing anything like that, on OS X 10.5...

Which OS X version are you using?  Does the behavior depend on what your default font is set to?  Can you perhaps narrow down when the problem first appeared using nightly builds?

Comment 3

[Alex]

It started happening with the retained layers landing, the pages have a fixed position background image which triggers it.

Comment 4

[philippe (part-time)]

Yeah, on 10.6, a build from 20100713 (pre retained layers) displays fine, but recent builds are crappy.
(font used is Helvetica on my side, but Helvetica Neue does the same).

Comment 5

[Anthony Ricaud (:rik)]

I'm on 10.6.

And yes, playing with background-attachment: scroll|fixed; fixes it.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Anthony, Alex, can you perhaps create a minimal-ish testcase?

Comment 7

[Alex]

Attachment: Testcase

There's also a testcase in Bug 579276, but that's a slightly different issue with the same core cause.

Comment 8

[Boris Zbarsky [:bzbarsky]]

OK, on 10.5 I can confirm the bug on that testcase.  This needs to block, imo.

Comment 9

[John Daggett (:jtd)]

The difference here is that FF3.6 uses subpixel antialiasing for the testcase while FF4 is using grayscale antialiasing.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

These W3C specs can be fixed by splitting nsDisplayBackground into one item per background component --- in particular, splitting colors from images --- then giving background image items accurate bounds, and then giving the topmost layer (containing the text) an opaque background that's pulled up from the solid color underneath it.

If we have a fixed-background image extending across the entire page, though, we'll still end up not using subpixel AA for text over the image. That makes scrolling much faster, even though the text doesn't look as good. Then again, in real-life situations, text over an image generally makes it harder to see the details of antialiasing.

Comment 11

[philippe (part-time)]

Attachment: semi-realistic test case

a large background-image covering the whole viewport

(In reply to comment #10)

> If we have a fixed-background image extending across the entire page, though,
> we'll still end up not using subpixel AA for text over the image. That makes
> scrolling much faster, even though the text doesn't look as good. Then again,
> in real-life situations, text over an image generally makes it harder to see
> the details of antialiasing.

That I'm not so sure. The background doesn't necessarily contain that much detail, and with background-size and related properties, text could look pretty poop.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

That testcase doesn't look as bad to me as others I've seen ... maybe it's just the font that gets chosen on my system.

There are other tradeoffs we can play with:
-- We can turn off layer-scrolling and just repaint in various situations where text is likely to look bad
-- We can turn on layer-scrolling temporarily and then turn it off when you stop scrolling (we do this now, but not for the viewport of the toplevel document)

These are tradeoffs in the sense that they will hurt scrolling performance.

I plan to start by focusing on the improvements that are pure wins, e.g. the first paragraph of comment #10, and then see what kinds of pages people are still unhappy about.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(Another clear win would be fixing bug 363861 by making text look less crappy, even if still grayscale-AA, in RGBA surfces.)

A home-run win would be to support subpixel-AA text in transparent surfaces via component-alpha surfaces, but performant support for component alpha is not likely anytime soon.

Comment 14

[John Daggett (:jtd)]

Last year a Chrome developer landed a patch in Webkit that attempts to delicately avoid offscreen buffers wherever possible, to try and avoid the fallback grayscale text rendering.  Might be interesting to take a look at what they've done.

See bug 363861, comment 75 for details.

Comment 15

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I looked at it and reported there. Basically it seems the main technique is to pull the contents of lower buffers into the background of a temporary buffer used in their equivalent of cairo's push_group. Nice technique, but doesn't directly apply here since our goal is to cache the contents of translucent layers.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm going to minus this on the grounds that there are some situations where for performance we definitely will have to resort to grayscale antialiasing. There are ways to fix many of the cases we're encountering though.

Comment 18

[John Daggett (:jtd)]

(In reply to comment #17)
> I'm going to minus this on the grounds that there are some situations where for
> performance we definitely will have to resort to grayscale antialiasing. There
> are ways to fix many of the cases we're encountering though.

And are those the majority of cases?  I think we're effectively opting for lower quality in a way that's hard to understand for authors that aren't designing something that is performance sensitive.  It's somewhat amusing that many of these cases crop up in rendering specs which are basically very simple HTML documents.

I think we should block on the "fix many of the cases we're encountering though" part.

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Sure, but is that this bug?

Comment 20

[Ben Turner (not reading bugmail, use the needinfo flag!)]

Which bug is it? Does it block 4 final?

Comment 21

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is basically going to be fixed in bug 579276.

Comment 23

[philippe (part-time)]

bug 579276 improved the situation (at least basic cases), but this got worse again in very recent days (openGL probably: bug 580405 ).

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a60414d076b5&tochange=5a2012482a63

Comment 26

[Joe Drew (not getting mail)]

Timothy, do you have any ideas here? If we have to, we can wait for Rob, but if we can get a fix earlier, we would love it.

Comment 27

[Timothy Nikkel (:tnikkel)]

I was had the understanding that what we need here is to implement the plan that was hashed out at the meeting on this topic at the work week.

Comment 28

[Timothy Nikkel (:tnikkel)]

Why did OpenGL layers on Mac make this worse anyways?

Comment 29

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Because BasicThebesLayer can choose not to retain itself and just draw directly to the backbuffer, if it's transparent and contains text. ThebesLayerOGL doesn't do that, and *can't* do that because we can't use Quartz to draw directly into the GL backbuffer.

Our plan is to fix this with bug 593733 --- two-pass component-alpha rendering with GL.

Comment 32

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Reassigning to Matt since he owns 593733

Comment 33

[Matt Woodrow (:mattwoodrow)]

This appears to be fixed now that component alpha for OpenGL has landed, can anyone still reproduce this with today's nightly?

Comment 34

[Andreea Pod]

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b10pre) Gecko/20110120 Firefox/4.0b10pre

The bug is still reproducible, I see it even with this font.

Comment 35

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Andreea, can you describe your testcase and results more precisely?

Comment 36

[Andreea Pod]

Attachment: screenshot

If you look at "t" or "e" letters you will see the problem.

Comment 37

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Andreea, can you please file a new bug for that? Include the contents of about:support. Check that subpixelAA works in other apps. Thanks.

Comment 38

[Andreea Pod]

I checked other applications and all was fine, just today I checked in Safari (Version 5.0.3 (6533.19.4)) and I could see that the text appears like on Firefox (like in the screenshot). Should I still file the bug?

Comment 39

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes

Comment 40

[Andreea Pod]

I just filed Bug 628985.