Grayscale antialiasing makes textareas ugly when scrolled

RESOLVED FIXED

Status

()

Core
Graphics
RESOLVED FIXED
7 years ago
a year ago

People

(Reporter: bz, Assigned: mattwoodrow)

Tracking

({regression})

Trunk
x86
Mac OS X
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

(Whiteboard: [hardblocker])

Attachments

(1 attachment)

BUILD: 2010-10-20 Mac nightly

STEPS TO REPRODUCE:
1)  Load https://bugzilla.mozilla.org/show_bug.cgi?id=604899
2)  Click the "Reply" link on comment 0
3)  Focus the textarea
4)  Hit the up arrow key until it starts scrolling up

ACTUAL RESULTS: when scrolling, antialiasing switches to grayscale and the text looks terrible.  5 seconds after the last scroll motion it switches back to subpixel.  This also happens when you type in textareas; it's been bugging the heck out of me when commenting on patches recently.

EXPECTED RESULTS: Ponies?  Or at least a faster transition to subpixel when scrolling is done.
blocking2.0: --- → ?
Component alpha for GL would fix this.
Depends on: 593733
Although we should be propagating the opaque white background from the page up into the scrolled layer.
In this case, the <textarea> itself has an opaque background.  It's just the <div> inside it that does not....  Can we make that work for us?  That wouldn't work for <select>, but does for textarea.
(In reply to comment #3)
> In this case, the <textarea> itself has an opaque background.  It's just the
> <div> inside it that does not....  Can we make that work for us?

Right, that's normal and I had that working. Maybe it regressed.
Assignee: nobody → roc
blocking2.0: ? → betaN+
Hmm, now I'm wondering if I ever had this working!

FrameLayerBuilder::FindOpaqueColorCovering returns false when we look for an opaque color we can pull into the scrolled contents of a <textarea>, because the area of the scrolled contents layer intersects the visible rects for both the borders and background of the <textarea>. In principle, it's certainly possible that the native theme could draw a background or border that's not uniform inside the textarea. However, we know that on popular themes that doesn't happen, and I guess we could try to exploit that somehow.

I assume Boris had GL layers enabled on his hardware, or he wouldn't have seen this.

I wonder if we should enhance the opaque color pull-up optimization, or focus on implementing component alpha ThebesLayers for GL. I think the latter.
> I assume Boris had GL layers enabled on his hardware,

Indeed; this is a recent mbp, so gl is all a-ok.

If component alpha for GL is doable in the 2.0 timeframe, that seems like a better solution; it'll certainly fix more cases.  ;)
Depends on: 593604

Updated

7 years ago
Duplicate of this bug: 607740

Updated

7 years ago
Duplicate of this bug: 610163
Duplicate of this bug: 611255
Duplicate of this bug: 612070
Any screenshot for what this looks like on Mac? I mean, is our grayscale rendering there generally poor quality? Grayscale shouldn't be -that- amazingly ugly. I mean, everybody on windows XP is still using grayscale.
Using the STR from this bug, it looks like taking a screenshot undoes the broken rendering, so the screenshots come out fine.

If you tell me how to force on non-transient grayscale antialiasing, I can probably get you a screenshot.

Note that the ugliness is particularly noticeable in this case because of the sudden transition from subpixel to greyscale... It makes it look like something's gone wrong.
Created attachment 490464 [details]
screenshot showing grayscale AA in scrolling textbox on OS X

The attached image shows two screenshots from this bug's STR. Top shows the grayscale-AA, rough-looking text that we get while the textfield is scrolling; bottom shows the subpixel-AA version that "pops" back into focus 5 seconds after scrolling finishes.

(The top image showing the appearance during scrolling was taken using Grab.app's "Timed Screen" capture.)
Hrm, well that's some pretty ugly grayscale rendering too I'd say.

Comment 15

7 years ago
Also happens on windows. Seems to be a DirectWrite thing, as it still happens when D2D and layers are disabled.
Bug 363861 will help here too.
Depends on: 363861
I'm currently seeing this in the location bar on OS X, too, when the URL is long enough to trigger (horizontal) scrolling there. It switches to ugly grayscale AA when scrolling, then pops back to subpixel after a pause.

(On Windows, the location bar seems to be permanently using grayscale AA (as do tab titles), which looks a little odd especially as subpixel is used when displaying potential awesomebar completions while I type.)
Keywords: regression
Whiteboard: [hard blocker]
Whiteboard: [hard blocker] → [hardblocker]
Whiteboard: [hardblocker] → [hardblocker][depends on 593733]
Reassigning to Matt since he owns 593733
Assignee: roc → matt.woodrow+bugzilla
(Assignee)

Comment 19

7 years ago
This seems to work for me now that component alpha for GL has landed. Can anyone still reproduce this with todays nightly?

Comment 20

7 years ago
Seems to be fixed for me in the nightly from the 18th.
Whiteboard: [hardblocker][depends on 593733] → [hardblocker]
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Yep, looks good to me too.  Thanks!
You need to log in before you can comment on or make changes to this bug.