Closed Bug 828206 Opened 8 years ago Closed 7 years ago

Fx 18 regression: loss of cleartype in portions of content (YouTube video page) after some scrolling

Categories

(Core :: Graphics: Text, defect)

18 Branch
x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox18 + wontfix
firefox19 + fixed
firefox20 --- unaffected
firefox21 --- unaffected
firefox-esr17 --- unaffected

People

(Reporter: al_9x, Assigned: mattwoodrow)

References

Details

(Keywords: regression)

Attachments

(4 files)

Attached image grayscale
xp, new profile

http://www.youtube.com/watch?v=SRKf7YLR52Q

it starts normal, after scrolling down, aa goes grayscale
present in 19.0b1

seems to be gone in 20.0a2 (2013-01-08)
Summary: Fx 18 regression: loss of cleartype in portions content (YouTube video page) after some scrolling → Fx 18 regression: loss of cleartype in portions of content (YouTube video page) after some scrolling
confirmed!

windows 7
use hardware acceleration = NO (!)
gfx.font_rendering.cleartype_params.rendering_mode = 2 (!)

on gmail.com ClearType lost colors even without scrolling.
habrahabr.ru/post/107607/ lost colors only after scrolling.
@CoolCmd: could you confirm it's fixed in FF21 as comment #1 claimed, please.
http://nightly.mozilla.org/
Flags: needinfo?(CoolCmd)
(In reply to Loic from comment #3)
Yes, in version 21a1 I don't see this bug.
Flags: needinfo?(CoolCmd)
Duplicate of this bug: 828241
Status: UNCONFIRMED → NEW
Ever confirmed: true
I first see this in 18.0b4, only with acceleration off.
In 19.0b1, only the scrolling issue occurs, I can't reproduce the Gmail non-scrolling issue.
20.0a2 is fine.

Problem appears in nightly here:
Last good nightly: 2012-12-04
First bad nightly: 2012-12-05

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa6e55a93b2&tochange=1942b4d64dc8

Fixed in nightly here:
Last good nightly: 2012-12-11
First bad nightly: 2012-12-12

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dfe323a663d&tochange=634180132e68

Anyone able to confirm that regression range?
Duplicate of this bug: 828032
Bug 828032 appears to be this same bug on OS X.
For pure entertainment value, go to http://caniuse.com/, give the Search field focus, then scroll the page down just enough to hide the search field… and watch the entire page of text toggle between smoothed and not, every half second. Coincides with the blink rate of the insertion point.

Didn't know if this would help with diagnostics, but it's just too awesome not to share. (Yes, I'm easily entertained.)

Haven't seen this on other pages yet…
Duplicate of this bug: 829943
I can reproduce the problem twitter attachment 701462 [details]  in Firefox18.0 and Firefox 19beta, but not in Aurora20.0a2 and Nightly21.0a1.

Regression window(m-c)
Good:
http://hg.mozilla.org/mozilla-central/rev/6fa6e55a93b2
Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20121204 Firefox/20.0a1 ID:20121204030754
Bad:
http://hg.mozilla.org/mozilla-central/rev/1942b4d64dc8
Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20121205 Firefox/20.0a1 ID:20121205030759
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6fa6e55a93b2&tochange=1942b4d64dc8

Regression window(aurora channel)
Good:
http://hg.mozilla.org/releases/mozilla-aurora/rev/fe20163490ec
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20121207 Firefox/19.0a2 ID:20121207042017
Bad:
http://hg.mozilla.org/releases/mozilla-aurora/rev/e8c2cb8c583f
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20121208 Firefox/19.0a2 ID:20121208042017
Pshlog:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=fe20163490ec&tochange=e8c2cb8c583f


Regression window(beta channel)
Good:
http://hg.mozilla.org/releases/mozilla-beta/rev/b5fab1c304d2
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20121207 Firefox/18.0 ID:20121207003552
Bad:
http://hg.mozilla.org/releases/mozilla-beta/rev/4e486ec47f47
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20121208 Firefox/18.0 ID:20121208005051
Pshlog:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=b5fab1c304d2&tochange=4e486ec47f47

in local build
Last Good: 735426e182ac
First Bad: b64693f63118
Triggered by:
b64693f63118	Matt Woodrow — Bug 810302 - When flattening layers together to avoid component alpha, attempt to pick the 'best' active scrolled root to minimize invalidation during scrolling. r=roc, a=lsblakk


And I also confirmed fixed range in comment#6.
I can confirm the patch of Bug 806099 fixes this problem.
(I applied the patch(https://hg.mozilla.org/mozilla-central/rev/1cc90ffcd6b6) of Bug 806099 to the current 19beta cset 2bb8638b277e, and build in locally)
Depends on: 806099
Duplicate of this bug: 830052
Duplicate of this bug: 830054
Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The user impact here does not seem severe (and there were no reports pre-release), so we're leaning towards fixing for the first time in FF19. Thoughts on the risk of uplifting bug 806099 to FF18?
Assignee: nobody → matt.woodrow
(In reply to Alex Keybl [:akeybl] from comment #15)
> Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The
> user impact here does not seem severe (and there were no reports
> pre-release), so we're leaning towards fixing for the first time in FF19.
> Thoughts on the risk of uplifting bug 806099 to FF18?

The impact may not be severe for the average user or those with certain monitor resolutions, but for those of us doing UI design, it's a bit of a PITA. I for one would love to see this fixed soonest.

But I'm not your flavor of developer so I certainly don't know what it will take to nail it. Thanks to all of you for your great work!
(In reply to Alex Keybl [:akeybl] from comment #15)
> Matt/Roc - we've seen a lot of duplicates of this bug filed for FF18. The
> user impact here does not seem severe (and there were no reports
> pre-release), so we're leaning towards fixing for the first time in FF19.
> Thoughts on the risk of uplifting bug 806099 to FF18?

It is not zero-risk, although the patch has been on trunk for a while and no regressions have been reported other than one isolated performance issue.
We should definitely uplift 806099 to beta though. Requested approval over there.
Duplicate of this bug: 830198
Same here.Fonts are very blurry on certain sites (gmail, lequipe.fr) as shown in attachment. Happened since updating to firefox 18. The loss of sharpness is very annoying visually.
Duplicate of this bug: 830843
Just for you to know, Launchpad has a bug about this particular problem:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1097763
Blocks: 833850
Bug 806099 was uplifted to FF19 on Beta. Should be resolved in that version.
Works fine on Firefox 19 beta 4, latest Nightly and Aurora. Can the status be changed to resolved? Or there is something to be added here?
Is it fixed in FF19?
it's fixed
It is not totally fixed.
Web pages looks good in FF 19 even after the scrolling; but text inside native widgets does not.
If you edit a long text in a field like the one im writing into and then scroll it; the subpixel antialiasing becomes gray after the scroll and after 2 or 3 seconds it automatically gets RGB antialias.
The same thing happens when i scroll the most viewed sites window with the awesome bar; 3 seconds delay.
If this can help to track the issue, i say that it does NOT happens in the history window.

My system is archlinux 32bit and i'm using firefox 19; see the attached video in a large window/fullscreen carefully.
hi, could my problem be related to this bug: https://bbs.archlinux.org/viewtopic.php?id=156456 ?
It was not present in ff17 but is present in ff18 and is still in ff19. It's really weird...
I'm Confirming this using FF19 Final and FF20b1 But I have found that for now it happens only if HW accel is enabled.

Additionally If I Zoom In/Out page (CTRL+Mouse Scroll) page is rendered correctly, looks like only default zoom is affected.

For Now I'm turning of HW Accel.

Haven't tested nightly for now.
As reference to Above archlinux page I'm using ATi HD 4890 and latest ATi Legacy Drivers 13.1
As peke said in comment #30: It's fixed in Firefox 19 (thanks!) but it can still happen when using hardware acceleration.

I turned on layers.acceleration.force-enabled today (Firefox 20 / Ubuntu 12.10 64-bit / nvidia 310.14) and started noticing the issue again.

I can see it clearly in gmail, and the strange thing is, that it's temporary: font hinting is strange when scrolling, and after you stop, in 2-3 seconds it jumps to being ok. I'm now attempting to record a screencast to show this.
Ah, my bad! No need to screencast, the issue is exactly what kokoko3k said in comment #28, but it doesn't need to be on a native widget (I see it on gmail).
I filed a bugreport for comment #29 https://bugzilla.mozilla.org/show_bug.cgi?id=847962
I don't know, maybe it's related..
@Comment #33: I'm not sure, I just tried to reproduce your issue and couldn't.
Have you tried it on another machine, just to be sure?
I did, it happens on both of my computers and even on Windows 7 (but isn't always *that* noticible). But maybe we should discuss this in the appropriate bugreport :)
Just note to my comment #30 that after upgrading to ATi Radeon HD 7950 and normal 13.1 driver I have no issues anymore, also FF version now is 19.0.2 will keep if issue reacure
This bug refers to an issue that could only occur *without* hardware acceleration.

Hardware acceleration is currently incomplete on linux, and is disabled by default for all users.

You're probably seeing bug 777170, which is because the component alpha (sub-pixel alpha text) support isn't completed.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Firefox 48b5 showes the mentioned behaviour again, while it had been fixed before.
For me the bug manifests in "strange" antialising appalied to GMail's red "Inbox" text label.

On my system I use:
AzureCanvasAccelerated	1
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	none
CairoUseXRender	0
You need to log in before you can comment on or make changes to this bug.