Closed Bug 582223 Opened 9 years ago Closed 9 years ago
Retained layers and fixed background forces grayscale rather than subpixel antialiasing
See attached screenshots. In Firefox 4, it looks worse, kind of JPEG artifacts.
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?
It started happening with the retained layers landing, the pages have a fixed position background image which triggers it.
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).
I'm on 10.6. And yes, playing with background-attachment: scroll|fixed; fixes it.
Anthony, Alex, can you perhaps create a minimal-ish testcase?
There's also a testcase in Bug 579276, but that's a slightly different issue with the same core cause.
OK, on 10.5 I can confirm the bug on that testcase. This needs to block, imo.
The difference here is that FF3.6 uses subpixel antialiasing for the testcase while FF4 is using grayscale antialiasing.
Summary: Strange antialising on W3C specs due to retained layers and fixed background → Retained layers and fixed background forces grayscale rather than subpixel antialiasing
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.
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.
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.
(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.
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.
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.
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.
blocking2.0: ? → -
(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.
Sure, but is that this bug?
Which bug is it? Does it block 4 final?
This is basically going to be fixed in bug 579276.
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
Component: Layout: Text → Graphics
QA Contact: layout.fonts-and-text → thebes
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.
Assignee: roc → 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.
Why did OpenGL layers on Mac make this worse anyways?
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.
Depends on: 593733
Assignee: nobody → roc
Whiteboard: [depends on 593733]
Whiteboard: [depends on 593733] → [depends on 593733][hard blocker]
Whiteboard: [depends on 593733][hard blocker] → [depends on 593733][hardblocker]
Reassigning to Matt since he owns 593733
Assignee: roc → matt.woodrow+bugzilla
This appears to be fixed now that component alpha for OpenGL has landed, can anyone still reproduce this with today's nightly?
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [depends on 593733][hardblocker] → [hardblocker]
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.
Andreea, can you describe your testcase and results more precisely?
If you look at "t" or "e" letters you will see the problem.
Andreea, can you please file a new bug for that? Include the contents of about:support. Check that subpixelAA works in other apps. Thanks.
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?
I just filed Bug 628985.
You need to log in before you can comment on or make changes to this bug.