Bug 63075 – REGRESSION (r88978): Text inside form controls looks really awful on Windows XP

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Adam Roben (:aroben)]

Created attachment 98001 [details]
screenshot

To reproduce:

1. Go to data:text/html,<input value=foo>

The text inside the text field has this horrible black fringing which makes it look too bold and chunky. See screenshot.

[Adam Roben (:aroben)]

Looks like this was caused by r88978: http://trac.webkit.org/changeset/88978

[Adam Roben (:aroben)]

<rdar://problem/9648113>

[Adam Roben (:aroben)]

Other folks at Apple have failed to repro this on Windows 7, even though I can repro on XP. My guess is that there's a difference in GDI behavior between XP and 7 that's causing the difference.

[Adam Roben (:aroben)]

The bug only occurs when subpixel antialiasing is enabled. Turning off ClearType, or setting Safari's font-smoothing preference to "Best for CRT", makes the bug go away.

[Adam Roben (:aroben)]

Created attachment 98164 [details]
Testcase

This testcase has the nice property that the upper-left pixel has a different appearance when the bug occurs and when it does not occur. This makes it easy to inspect the memory for the page's bitmap to see what's going on.

[Adam Roben (:aroben)]

I'm stepping through the code using the attached testcase.

Before RenderThemeWin::paintTextField is called, the bitmap is filled with 0xffffffff. RenderThemeWin::paintTextField then fills the text field with 0x00ffffff. Note that the alpha channel has been changed to 0.

Soon later, Font::drawGlyphs is called. At this point the first few pixels are:

0x08000808 0xff728080 0xff808080 0xff808080

The first pixel here is nearly-transparent nearly-black. The second pixel is opaque gray with the red channel darkened a little. The third and fourth pixels are opaque gray.

Over on the UI process side, ::BitBlt does preserve the alpha channel, so these same pixels end up written into the page's BackingStore bitmap. But when the page is displayed on screen, the alpha channel will be ignored, so the nearly-transparent nearly-black pixel will just become a nearly-black pixel, causing the ugly appearance.

[Adam Roben (:aroben)]

One potential fix is to change DrawingAreaImpl::createGraphicsContext to create a GraphicsContext that does not support alpha. I.e., change this:

    return adoptPtr(new GraphicsContext(bitmapDC, true));

to this:

    return adoptPtr(new GraphicsContext(bitmapDC, false));

Doing so gives the following pixel values:

0xffffebbf 0xff918080 0xff808080 0xff808080

You can see that the first two pixels have changed to be opaque nearly-white and opaque nearly-gray, which is much better than opaque nearly-black!

[Adam Roben (:aroben)]

Making this change also does not reintroduce bug 62690.

[Adam Roben (:aroben)]

Rolling out r88978 changes the behavior of RenderThemeWin::paintTextField so that the 0xffffffff pixels keep that value. DrawThemeBackground still fills the temporary bitmap inside the LocalWindowsContext with 0x00ffffff as before, but GraphicsContext::releaseWindowsContext ignores the alpha channel when blitting back into the original GraphicsContext, so opaque white is preserved.

[Adam Roben (:aroben)]

Created attachment 98180 [details]
Don't use an alpha channel when drawing the web page on Windows

[Adam Roben (:aroben)]

Committed r89436: <http://trac.webkit.org/changeset/89436>