758862 - Text changes appearance when scrolling

Status: RESOLVED WORKSFORME

(Core :: Graphics: Text, defect)

Description

[Bram Speeckaert]

Attachment: Screenshot 1

1) Open the URL (http://mattst88.com/blog/2012/05/17/Optimizing_pixman_for_Loongson:_Process_and_Results/)
2) Scroll down. The font changes in appearance.

This behavior does not occur in Google Chrome. I could not replicate this issue on Windows 7, so I'm thinking this might be exclusive to Windows XP.

Comment 1

[Bram Speeckaert]

Attachment: Screenshot 2 - after scrolling down

Comment 2

[Jonathan Kew [:jfkthame]]

Wow, that's ugly. The scrolled rendering here reminds me of bug 678449 and other examples of poor light-on-dark text, but as it's XP, this must be using GDI rather than DW/D2D; also, the connection with scrolling is interesting - suggesting a Layers connection, maybe.

Moving this to Graphics, as it looks like a rendering rather than layout issue.

Does the problem occur on Win7 if you *disable* hardware acceleration in Options, and restart the browser?

Comment 3

[Bram Speeckaert]

Nope, rendering on Windows 7 is still fine, regardless of hardware acceleration. I tried playing around with some of the other settings related to graphics in about:config, but none of them seemed to bring up the issue, while it always occurs on XP. I should however note that I run XP and 7 on different machines (XP on a measly netbook with Intel graphics).

If there is any additional information that I should supply, let me know.

Comment 4

[Alice0775 White]

Confirmed when using font Arial
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120525113255
Maybe related to Bug 664966

Comment 5

[Alice0775 White]

Graphics
Adapter Description : ATI Radeon HD 4300/4500 Series
Vendor ID : 0x1002
Device ID : 0x954f
Adapter RAM : 512
Adapter Drivers : aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Driver Version : 8.961.0.0
Driver Date : 4-5-2012
Direct2D Enabled : true
DirectWrite Enabled : true (6.1.7601.17789)
ClearType Parameters : Gamma: 2200 Pixel Structure: RGB ClearType Level: 50 Enhanced Contrast: 200 
WebGL Renderer : Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series) -- OpenGL ES 2.0 (ANGLE 1.0.0.1041)
GPU Accelerated Windows : 1/1 Direct3D 10
AzureBackend : direct2d

Comment 6

[Alice0775 White]

Attachment: reduced html

Comment 7

[Alice0775 White]

Attachment: reduced html reproduced with/without HWA

Comment 8

[Alice0775 White]

Attachment: reduced html reproduced with/without HWA

more clearly

Comment 9

[Bram Speeckaert]

I did some more testing and I discovered that my initial findings of the behavior not occurring on Windows 7 were false; it does in fact happen there as well.

At first I could only replicate this behavior with HWA on. After some digging, it turned out I had 'gfx.direct2d.disabled' set to true in about:config, which seems to be ignored entirely when HWA is turned on. So it seems that Direct2D subpixel rendering is to blame (on Windows 7 at least, because XP lacks Direct2D IIRC):

-Setting 'gfx.direct2d.disabled' to false: The issue shows up regardless of HWA setting.
-Setting 'gfx.direct2d.disabled' to true: The issue goes away with HWA off. Well, if you watch closely you can still see the subpixel rendering change, but the difference is very subtle (unlike with Direct2D on, with which the difference makes the text look bold). Enabling HWA causes Direct2D to always be used.

I also noticed that not just scrolling affects the text, but also resizing the screen. Scrolling and resizing seems to make the font snap to the pixel grid in different ways, causing it to become either very thick and bright or very thin and dark.

Also, the difference in page size between Direct2D on/off is also very noticeable with the reduced testcase.

Comment 10

[Alice0775 White]

Regression window(m-c)
Good
http://hg.mozilla.org/mozilla-central/rev/b687cabf75a1
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120410 Firefox/14.0a1 ID:20120410122159
Bad:
http://hg.mozilla.org/mozilla-central/rev/4db1292be760
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120410 Firefox/14.0a1 ID:20120410130200
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b687cabf75a1&tochange=4db1292be760

Regression window(m-c)
Good
http://hg.mozilla.org/integration/mozilla-inbound/rev/a235528adace
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120409 Firefox/14.0a1 ID:20120410041149
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/25a13d26509d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120410 Firefox/14.0a1 ID:20120410054929
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=a235528adace&tochange=25a13d26509d

Regressed by:
25a13d26509d	Robert O'Callahan — Bug 733607. Restructure logic to compute snapped bounds of display items in layer coordinates. Moves responsibility for computing snapped bounds from within the display items to callers of GetBounds/GetOpaqueRegion. r=tnikkel Previously we snapped the results of nsDisplayItem::GetBounds and nsDisplayItem::GetOpaqueRegion internally. By tracking which display items were inside transforms, we disabled snapping quite conservatively whenever an ancestor had a transform, which is undesirable. With this patch, we don't snap inside GetBounds or GetOpaqueRegion, but just return a boolean flag indicating whether the item will draw with snapping or not. This flag is conservative so that "true" means we will snap (if the graphics context has a transform that allows snapping), but "false" means we might or might not snap (so it's always safe to return false). FrameLayerBuilder takes over responsibility for snapping item bounds. When it converts display item bounds to layer pixel coordinates, it checks the snap flag returned from the display item and checks whether the transform when we draw into the layer will be a known scale (the ContainerParameters scale factors) plus integer translation. If both are true, we snap the item bounds when converting to layer pixel coordinates. With this approach, we can snap item bounds even when the items have ancestors with active transforms.

Comment 11

[Bram Speeckaert]

Attachment: Direct2D on (old test case)

Comment 12

[Bram Speeckaert]

Attachment: Direct2D off (old test case)

Comment 13

[Bram Speeckaert]

Attachment: Direct2D on (new test case)

Comment 14

[Bram Speeckaert]

Attachment: Direct2D off (new test case)

Comment 15

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

I can't reproduce this myself. However, I suspect this is a problem with us not doing correct gamma. Right Bas?

Comment 16

[Alice0775 White]

Screen capture: http://space.geocities.jp/alice0775/test/20120529_1452_43.swf.html

Comment 17

[Bram Speeckaert]

Attachment: AnandTech bad

AnandTech on Nightly 19.0a1 (2012-11-09)

Comment 18

[Bram Speeckaert]

Attachment: AnandTech good

AnandTech on 16.0.2

Comment 19

[Bram Speeckaert]

Resizing the window horizontally makes the font change between good and bad rendering. All previous test cases still seem to work fine though.

Comment 20

[Bram Speeckaert]

Attachment: AwesomeBar bad

Highlighted element also suffers from faulty subpixel font rendering on Windows XP

Comment 21

[Bram Speeckaert]

Attachment: AwesomeBar good

Resizing the window width makes the font render properly again sometimes

Comment 22

[Bram Speeckaert]

All the issues here seem to have been fixed now on my end.

Comment 23

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

Alice, do you agree?

Comment 24

[Alice0775 White]

Yes. I agree.

I cannot reproduce the problem with/wothout HWA anymore in Windows7 Firefox17.0 and later  :).

Comment 25

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

Great, thanks.

Can you find a fix range? Maybe we should uplift this to Aurora and Beta?

Comment 26

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

WFM since we don't know what fixed this (yet)

Comment 27

[Bram Speeckaert]

Bad news, I found another place with issues identical to the very first case I reported here: http://fail0verflow.com/blog/index.html

More bad news, this problem exists in the latest Nightly (20.0a1 2012-12-14) as well as versions as old as Firefox 16.0.2 (that's the oldest I had around for a quick test, so the problems were probably introduced even before that).

Again, the text seems to get 'fixed' occasionally while playing around with the scrolling and the window size. I'll attach some screenshots in a bit, all on Windows XP.

Comment 28

[Bram Speeckaert]

Attachment: Fail0verflow bad

Note how the window is not maximized, as no amount of scrolling would make it look right in that case.

Comment 29

[Bram Speeckaert]

Attachment: Fail0verflow good

Same window size, but scrolled down slightly. Scrolling down further will at some point make the font bad again.

Comment 30

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

It can be bug #810274, see regression range there

Comment 31

[Bram Speeckaert]

I've finally figured out how to reproduce the problem on the fail0verflow website. Turns out that the font is only bad when the page's black background is visible. As soon as the final pixels of the background are no longer in sight, the font is redraw for some reason (verified with paint flashing) and looks alright. Make the background visible again, and the font goes bad again.

I managed to reproduce this on Windows XP (no HWA) and Windows 7 (with and without HWA). This also explains why I couldn't reproduce it on my Windows 7 machine; scrolling the background away is a lot harder on a 1920x1200 display than on my netbook with 1024x600.

STR:
1. Go to http://fail0verflow.com/blog/2013/megafail.html
2. Resize the window in such a way that you can scroll the black background (on the top and on the sides) entirely out of sight
3. Scroll until all of the black background is gone, but with the text in sight

Comment 33

[Alice0775 White]

Screenshot before/after scroll: attachment 8363025 [details]

Steps To Reproduce:
1. Open http://mattst88.com/blog/2012/05/17/Optimizing_pixman_for_Loongson:_Process_and_Results/
2. Scroll down. 
3. Change browser width slowly if necessary

Actual results:
The font changes in appearance.

Comment 34

[Alice0775 White]

This happens with regardless of HWA on/off.
This also happen Windows7

Graphics
--------

Adapter Description: ATI Radeon HD 4300/4500 Series
Adapter Drivers: aticfx64 aticfx64 aticfx32 aticfx32 atiumd64 atidxx64 atiumdag atidxx32 atiumdva atiumd6a atitmm64
Adapter RAM: 512
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 50 Enhanced Contrast: 50
Device ID: 0x954f
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7601.18245)
Driver Date: 4-29-2013
Driver Version: 8.970.100.1100
GPU #2 Active: false
GPU Accelerated Windows: 2/2 Direct3D 10
Vendor ID: 0x1002
WebGL Renderer: Google Inc. -- ANGLE (ATI Radeon HD 4300/4500 Series Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: false
AzureCanvasBackend: direct2d
AzureContentBackend: direct2d
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Comment 35

[u279076]

Alice, can you please check if this still reproduces?

Comment 36

[Alice0775 White]

no longer reproduced on Nightly51 , Firefox49.0b8.