606075 - Grayscale antialiasing makes textareas ugly when scrolled

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Boris Zbarsky [:bzbarsky]]

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.

Comment 1

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

Component alpha for GL would fix this.

Comment 2

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

Although we should be propagating the opaque white background from the page up into the scrolled layer.

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

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

(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.

Comment 5

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

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.  ;)

Comment 11

[Bas Schouten (:bas.schouten)]

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.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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.

Comment 13

[Jonathan Kew [:jfkthame]]

Attachment: 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.)

Comment 14

[Bas Schouten (:bas.schouten)]

Hrm, well that's some pretty ugly grayscale rendering too I'd say.

Comment 15

[u310142]

Also happens on windows. Seems to be a DirectWrite thing, as it still happens when D2D and layers are disabled.

Comment 16

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

Bug 363861 will help here too.

Comment 17

[Jonathan Kew [:jfkthame]]

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.)

Comment 18

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

Reassigning to Matt since he owns 593733

Comment 19

[Matt Woodrow (:mattwoodrow)]

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

Comment 20

[chiklit]

Seems to be fixed for me in the nightly from the 18th.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Yep, looks good to me too.  Thanks!