632423 - Text poorly rendered with hardware acceleration off (most noticeable with white text)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[orangezilla]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; rv:2.0b11pre) Gecko/20110201 Firefox/4.0b11pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; rv:2.0b12pre) Gecko/20110208 Firefox/4.0b12pre

Various sites show poor rendering of text with hardware acceleration off, problem shows up more obviously with white text on dark background, although it is still there with dark text on light background, sometimes not all text on page is broken, no problems in other browsers:

http://tv.sky.com/
http://arena.gamespy.com/
http://www.myspace.com/adelelondon 
http://www.disney.co.uk/disney-parks/
http://espn.go.com/ 

Reproducible: Always

Steps to Reproduce:
1. Make sure hardware acceleration is unticked in options>advanced>general.
2.Go to http://tv.sky.com/, text is broken in Sky Entertainment banner, in programme selection boxes, not in above text (read more /watch video), days of week frame text is broken, all text at foot of page broken.
3. Go to http://arena.gamespy.com/ mouse over games, get drop down menu with poor text, click 'All Games' under PC, mouse over Games, the text is now OK
4. Go to http://www.myspace.com/adelelondon text is poorly rendered over most of page, most noticeable white on dark but also footer of page dark on light.
5. Go to http://www.disney.co.uk/disney-parks/ text noticeably bad on far left below 'Travel Home'.
6. Go to http://espn.go.com/ mouse over any text on the black My ESPN bar, drop down menu appears and all text on bar becomes poorly rendered.
Actual Results:  
Text is poorly rendered on either the majority of a page or on menu bars.

Expected Results:  
Text should render correctly as in other browsers, see comparison screenshots below:

http://forums.mozillazine.org/viewtopic.php?f=23&t=2095643&p=10394519#p10394519
http://forums.mozillazine.org/viewtopic.php?f=23&t=2095643&p=10396493#p10396493


Issue occurs in Beta 7 and latest nightly.

Comment 1

[orangezilla]

NOTE: you should restart firefox after disabling hardware acceleration in options.

Comment 2

[(mostly gone) XtC4UaLL [:xtc4uall]]

When did this regress?

Comment 3

[vimes_2004]

After turning off hardware acceleration and restarting the latest nightly I can agree with each and every one of those findings which have been linked.
However as I always have acceleration on I would not know when this issue occurred.

Comment 4

[orangezilla]

Testing again it appears the drop down menu issues on ESPN and Gamespy Arena were NOT broken in Beta 7, but the general text on Sky, Myspace and Disney were, doing some more testing to discover when the regressions for both occurred.

Comment 5

[orangezilla]

Attachment: Image comparing text on https secure tabs Beta 6,8,11

This also seems to have affected the bars on all secure https: addresses, i.e.Bugzilla as shown in the attachment

I believe the changes occurring on these are connected to the same changes on the ESPN/Gamespy Arena drop down menus- these first changed between 10-11th November 4 Beta 8Pre builds from the lighter shading on the left to the darker in center which makes text look thinner and less clear, a second change occurred between December 31st and January 9th Beta 9Pre which caused (I think) greyscale anti aliasing which looks terrible.

Comment 6

[orangezilla]

Attachment: Image comparing text on Myspace Adele Beta 1,2,12pre0902

A similar change occurred in the Myspace, Sky, and Disney pages however this time the change to darker shading occurred between FF 4 Beta 1 and Beta 2, but they also changed to greyscale AA between Dec 31st-Jan 9th 9Pre builds.

I should also add the issue with the text on the drop down menus changing to darker or greyscale AA on ESPN and Gamespy Arena only seems to occur if the menu overlaps a Flash ad/video, if Flash is disabled the problem completely goes away.

Comment 7

[orangezilla]

Attachment: Image comparing text on Disney Parks Beta 1, 2, and 11

Image at actual size clearly showing degradation of text on the Disney site from (left-right) Beta 1, Beta 2, Beta 11. The same changes occurred with the Sky & Myspace sites.

Comment 8

[orangezilla]

OK looks like there are 3 separate issues here, albeit with a similar deteriation:

the change with Disney, Sky and Myspace pages occurred between the 15-16th July Beta 2Pre builds:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/07/2010-07-15-04-mozilla-central/ Correctly rendered text

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/07/2010-07-16-04-mozilla-central/ Darker shading on AA, leading to thinner, less clear text

the change in the text in the https: bars i.e. bugzilla, mozilla addons occurred between the 19th-20th October Beta 8Pre builds:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-19-04-mozilla-central/ Correctly rendered text

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/10/2010-10-20-04-mozilla-central/ Darker shading on AA, leading to thinner, less clear text

The issue with the ESPN and Gamespy Arena dropdown menu text deteriorating when it overlaps a Flash ad or video occurred between the 10th-11th November Beta 8Pre builds:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/11/2010-11-10-04-mozilla-central/

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/11/2010-11-11-04-mozilla-central/

I am uncertain how to generate pushlogs for these builds, would appreciate if someone could post these, thanks.

Comment 9

[Timothy Nikkel (:tnikkel)]

I'll teach you how to do it.
To generate pushlogs you use this format:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=<firstrevid>&tochange=<secondrevid>

Then you need to get the rev id for each build. For more recent builds there is a txt file in the ftp directory along with the build, the first thing in the file is the timestamp, the second thing is the revision id. For older builds where there is no txt file available you need to look inside the zip file. You can either extract the whole zip file and run firefox from there and then load about:buildconfig, or you can just look in the file application.ini.

Comment 10

[orangezilla]

(In reply to comment #9)
> I'll teach you how to do it.
> To generate pushlogs you use this format:

Thanks Timothy, here's the three logs for the original change to darker subpixel AA shading, leading to thinner, less clear text not used on other browsers with these pages:

for the Disney, Sky and Myspace page issues:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7

For the text in secure https: bars(?):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c9df0c5cbf8c&tochange=7aa9763e9d41

for the ESPN and Gamespy Arena dropdown menu text deteriorating when
overlapping a Flash ad or video:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df1d1ff6b489&tochange=0f17e5f1eb01

All the above examples switched to greyscale AA sometime between 31st Dec-10th Jan but I think this is likely not the cause of the original problems
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b083bc8b79ab&tochange=f9f48079910f

Comment 11

[Timothy Nikkel (:tnikkel)]

Thanks for finding the regression ranges and converting them to this format!

(In reply to comment #10)
> for the Disney, Sky and Myspace page issues:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5fda39cd703c&tochange=96de199027d7

This will be retained layers, bug 564991.

> For the text in secure https: bars(?):
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c9df0c5cbf8c&tochange=7aa9763e9d41

Does your system use D3D10 layers? If so then it is probably enabling D3D10 layers by default, bug 605547.

> for the ESPN and Gamespy Arena dropdown menu text deteriorating when
> overlapping a Flash ad or video:
> http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df1d1ff6b489&tochange=0f17e5f1eb01

Guessing this is bug 596451.

Comment 12

[Timothy Nikkel (:tnikkel)]

What is your hardware? Can you paste the graphics portion of about:support?

Comment 13

[orangezilla]

Info below, note that all the issues above are occurring with hardware acceleration turned off though (for the about:support I turned hw acceleration on):

Adapter Description: NVIDIA GeForce 9800 GT
Vendor ID: 10de
Device ID: 0614
Adapter RAM: 1024
Adapter Drivers: nvd3dum nvwgf2um,nvwgf2um
Driver Version: 8.17.12.6658
Driver Date: 1-7-2011
Direct2D Enabled: true
DirectWrite Enabled: true (6.1.7600.20830, font cache n/a)
WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)GPU Accelerated Windows: 1/1 Direct3D 10

Comment 14

[Kurt Felton]

Having this same issue. Here is my information for about:support if it helps:

Adapter Description: ATI Radeon HD 5800 Series
Vendor: ID1002
Device ID:  6898
Adapter RAM:  1024
Adapter Drivers:  aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64
Driver Version: 8.812.0.0
Driver Date: 1-4-2011
Direct2D Enabled: false
DirectWrite Enabled:  false (6.1.7600.20830, font cache n/a)
WebGL Renderer: Google Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.541)GPU Accelerated Windows:  0/2

Comment 15

[orangezilla]

Should I list these as separate bugs? Still getting the same problems on latest nightly.

Comment 16

[orangezilla]

I have mentioned the ESPN and Gamespy drop down menu text changing when over Flash content on this other bug relating to Nike sites as it looks like the same changes may have affected them all:
https://bugzilla.mozilla.org/show_bug.cgi?id=634380

Comment 17

[orangezilla]

Problem also exists on Google Art
http://www.googleartproject.com/

Comment 18

[orangezilla]

Interestingly the text on that page only breaks when the background image loads.

Comment 19

[orangezilla]

http://www.nvidia.com/page/home.html affected by the drop down menu text deteriorating over flash content, looks like this probably occurs in all similar situations

Comment 20

[orangezilla]

Also http://www.samsung.com/uk/

Comment 21

[Timothy Nikkel (:tnikkel)]

Can someone that sees this bug take one of the pages showing the problem and reduce it into a simple testcase?

Comment 22

[Kurt Felton]

(In reply to comment #21)
> Can someone that sees this bug take one of the pages showing the problem and
> reduce it into a simple testcase?

Are you not seeing the bug on your end with HA turned off?

Comment 23

[Timothy Nikkel (:tnikkel)]

First off I don't have access to Windows 7 right now, so if that is important I can't check. Secondly, I'm not sure what I'm looking for: am I looking for subpixel AA (or lack thereof) or am I just looking for if "fonts look good"? The latter I am prone to decide differently then you might.

With that said I checked all the sites in this bug for subpixel AA (which I understand most people prefer) on Linux with no hardware acceleration, and they all had subpixel AA.

Comment 24

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

Bas, could this be our "manual" drawing of subpixel-AA DWrite text to RGBA surfaces?

Comment 25

[orangezilla]

(In reply to comment #23)
> First off I don't have access to Windows 7 right now, so if that is important I
> can't check. Secondly, I'm not sure what I'm looking for: am I looking for
> subpixel AA (or lack thereof) or am I just looking for if "fonts look good"?
> The latter I am prone to decide differently then you might.
> 
> With that said I checked all the sites in this bug for subpixel AA (which I
> understand most people prefer) on Linux with no hardware acceleration, and they
> all had subpixel AA.
I don't know what the technical term is for the 1st change, but if you look at the attachments at the top, there were two changes from how it should be (in comparison to how all other browsers render the text without hardware acceleration), the first turned the anti aliasing shading darker, the second change turned it greyscale, these changes occured at different times for the 3 sets of sites, pushlogs listed in comment 10 .

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to comment #24)
> Bas, could this be our "manual" drawing of subpixel-AA DWrite text to RGBA
> surfaces?

The deterioration in subpixel-AA appearance looks similar to that, but bug 622482 didn't land until 2011-01-16, long after the regressions noted in comment #8, etc.

Is it possible that somewhere in (retained?) layers, something is getting composited multiple times into the same destination, thereby darkening all the partially-opaque AA pixels around the edges of the glyphs?

Comment 27

[Jonathan Kew [:jfkthame]]

(In reply to comment #26)
> (In reply to comment #24)
> > Bas, could this be our "manual" drawing of subpixel-AA DWrite text to RGBA
> > surfaces?
> 
> The deterioration in subpixel-AA appearance looks similar to that, but bug
> 622482 didn't land until 2011-01-16, long after the regressions noted in
> comment #8, etc.
> 
> Is it possible that somewhere in (retained?) layers, something is getting
> composited multiple times into the same destination, thereby darkening all the
> partially-opaque AA pixels around the edges of the glyphs?

Though as it's now lost subpixel-AA altogether and gone to grayscale in these examples, it's hard to tell whether that would still be happening.

Comment 28

[orangezilla]

Attachment: Comparison of youtube resolution pop up SR Iron(Chrome) vs FF4 13pre

Drop down menu problem over flash also affecting the the resolution pop up box on youtube.

Comment 29

[orangezilla]

Also does similar for all text pop ups, i.e. time, mute, pop out, expand, fullscreen on youtube.

Comment 30

[orangezilla]

The text overlaying the video at the end of youtube videos is also affected by the greyscale AA bug, but confusingly Iron(Chrome)9 is also affected, even though it is not affected in the pop up text, as is Firefox 4 and Internet Explorer 9 RC with hardware acceleration on. The only combinations I've found where text does not drop to greyscale on either the youtube pop up text or the text overlaying the video at the end is Opera 11 and IE9 RC with hardware acceleration off.

Comment 31

[orangezilla]

Actually the latest Chrome 9 has it fixed, Iron 9 is a slightly older version with Google updater as well as other stuff stripped out. Since youtube is such a major site should I a nom this separately as it occurs with both hardware acceleration off and on?

Comment 32

[Bas Schouten (:bas.schouten)]

I'm not sure this blocks.

This should be moved to layout probably since this has to do with the layer tree and the way things are marked in there (apparently this is a SINGLE_CHANNEL_ALPHA layer, because we don't notice there's text. -Or- for some reason we don't think it has an opaque background we can copy up). But maybe that doesn't need to be so, but it seems like something for Layout to look at. roc/tn, please move back if you disagree with my assessment.

Comment 33

[Timothy Nikkel (:tnikkel)]

Bas, so you can reproduce this?

Comment 34

[orangezilla]

Attachment: Comparison of end of youtube video beta5pre 2708 (top) vs 2808 (bottom)

I think the problem in having gotten people to reproduce this is that there about 3-4 separate issues here per the different pushlogs in comment 10 . The youtube issue mentioned in comment 28 - 31 I believe is separate as well as the text popups are part of flash unlike the javascript drop down menus over flash issue, I have managed to find the regression range for the youtube greyscale text problem, this has been broken ever since the hardware acceleration option was added in 5pre between 27th-28th August

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e1d55bbd1d1d&tochange=6e3f6d18c124

Comment 35

[Bas Schouten (:bas.schouten)]

(In reply to comment #33)
> Bas, so you can reproduce this?

I can't say I tried. But looking at the screenshots and considering people are saying the subpixel AA disappears both with and without hardware acceleration, it shouldn't have anything to do with manual sub-pixel AA or those things.

Comment 36

[orangezilla]

(In reply to comment #35)
> (In reply to comment #33)
> > Bas, so you can reproduce this?
> 
> I can't say I tried. But looking at the screenshots and considering people are
> saying the subpixel AA disappears both with and without hardware acceleration,
> it shouldn't have anything to do with manual sub-pixel AA or those things.
Sorry, looks like I have confused things here, only the youtube issue shown on the attachment in comment 34 occurs with both hardware acceleration on or off, all the other issues i.e. listed in comment 10 only occur with hardware acceleration off.

Comment 37

[Emanuel Hoogeveen [:ehoogeveen]]

Since these issues have different regression ranges, should they be spun off into different bugs and this one kept as a tracking bug?

Comment 38

[Bas Schouten (:bas.schouten)]

(In reply to comment #36)
> (In reply to comment #35)
> > (In reply to comment #33)
> > > Bas, so you can reproduce this?
> > 
> > I can't say I tried. But looking at the screenshots and considering people are
> > saying the subpixel AA disappears both with and without hardware acceleration,
> > it shouldn't have anything to do with manual sub-pixel AA or those things.
> Sorry, looks like I have confused things here, only the youtube issue shown on
> the attachment in comment 34 occurs with both hardware acceleration on or off,
> all the other issues i.e. listed in comment 10 only occur with hardware
> acceleration off.

That might be because those are 'component alpha' layers which we can't do without hardware acceleration.

Comment 39

[orangezilla]

(In reply to comment #37)
> Since these issues have different regression ranges, should they be spun off
> into different bugs and this one kept as a tracking bug?
Yeah, I suggested that in comment 15 :D, will be happy to do it if noone else wants to do so....

(In reply to comment #38)
> That might be because those are 'component alpha' layers which we can't do
> without hardware acceleration.
The comment 10 issues? They did once work fine without acceleration though?

Comment 40

[Bas Schouten (:bas.schouten)]

> (In reply to comment #38)
> > That might be because those are 'component alpha' layers which we can't do
> > without hardware acceleration.
> The comment 10 issues? They did once work fine without acceleration though?

Yes, we used to just draw subpixel AA to anything with GDI. This is a 'bug' technically since it would only look right against a black background, when drawn against a different color the subpixel anti-aliasing would be incorrect for the eventual blending function.

This bug was fixed and a transparent layer now either uses component alpha blending, and always gets correct sub-pixel AA. Or it doesn't get sub-pixel AA at all. See bug 363861.

Comment 41

[orangezilla]

(In reply to comment #40)
> > (In reply to comment #38)
> > > That might be because those are 'component alpha' layers which we can't do
> > > without hardware acceleration.
> > The comment 10 issues? They did once work fine without acceleration though?
> 
> Yes, we used to just draw subpixel AA to anything with GDI. This is a 'bug'
> technically since it would only look right against a black background, when
> drawn against a different color the subpixel anti-aliasing would be incorrect
> for the eventual blending function.
> 
> This bug was fixed and a transparent layer now either uses component alpha
> blending, and always gets correct sub-pixel AA. Or it doesn't get sub-pixel AA
> at all. See bug 363861.
I note you said it "might be because those are 'component alpha' layers ", so you are not certain what the issue is yet? The text on these pages (except for the youtube issue) render perfectly on all other browsers so I'm not sure why it would be possible for them to do this but not FF4? Anyway, I'll file the bugs separately in a few minutes so people can take a closer look at the issues.

Comment 42

[Bas Schouten (:bas.schouten)]

(In reply to comment #41)
> (In reply to comment #40)
> > > (In reply to comment #38)
> > > > That might be because those are 'component alpha' layers which we can't do
> > > > without hardware acceleration.
> > > The comment 10 issues? They did once work fine without acceleration though?
> > 
> > Yes, we used to just draw subpixel AA to anything with GDI. This is a 'bug'
> > technically since it would only look right against a black background, when
> > drawn against a different color the subpixel anti-aliasing would be incorrect
> > for the eventual blending function.
> > 
> > This bug was fixed and a transparent layer now either uses component alpha
> > blending, and always gets correct sub-pixel AA. Or it doesn't get sub-pixel AA
> > at all. See bug 363861.
> I note you said it "might be because those are 'component alpha' layers ", so
> you are not certain what the issue is yet? The text on these pages (except for
> the youtube issue) render perfectly on all other browsers so I'm not sure why
> it would be possible for them to do this but not FF4? Anyway, I'll file the
> bugs separately in a few minutes so people can take a closer look at the
> issues.

It depends, in general I'd say on this page it would be possible to copy up the background (which is what some others do) and do sub-pixel AA.

Also possibilities of what you can do differ between how you choose to divide your layers for accelerated compositing. There's a performance/quality tradeoff there, you could draw everything in an immediate mode and you'd essentially always be able to do subpixel anti-aliasing except when having to deal with group opacity, but even then there's a lot you can do. But it would strongly degrade performance.

Comment 43

[orangezilla]

(In reply to comment #42)
> It depends, in general I'd say on this page it would be possible to copy up the
> background (which is what some others do) and do sub-pixel AA.
> 
> Also possibilities of what you can do differ between how you choose to divide
> your layers for accelerated compositing. There's a performance/quality tradeoff
> there, you could draw everything in an immediate mode and you'd essentially
> always be able to do subpixel anti-aliasing except when having to deal with
> group opacity, but even then there's a lot you can do. But it would strongly
> degrade performance.
OK, well here is the first spin off, bug 637073 , I have identified certain occasions where text is correctly aliased, such as before background loads, scrolling past a certain object, or a frame loading new content which maybe will give you a clue as to why the greyscale AA is happening.

Comment 44

[orangezilla]

Second spin off for greyscale AA in https secure verification box: bug 637081 , I am a little tired now so will file the other two spinoffs tomorrow.

Comment 45

[orangezilla]

Last two spin offs:

Bug 637139 Drop down menus overlapping flash content have text rendered in greyscale AA, hardware acceleration off 

Bug 637142 Pop ups and overlayed text on youtube is greyscale AA antialiased

Comment 46

[Kurt Felton]

Wanted to add that regarding the ESPN site, that the menu seemed to work like normal and didn't change the way the fonts looked when hovering over a menu when I did not have flash installed. As soon as I installed flash it's back to the normal behavior where it looks off, when hovering over a menu.

Comment 47

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

Attachment: fix

BasicLayers doesn't do retained component alpha, so for component-alpha layers it just draws the layer contents directly into a container layer or the backbuffer. When we draw into the backbuffer and it's RGBA, SetAntialiasingEnabled disables subpixel AA --- that's what seems to be happening in the cases in this bug that I looked at.

Fortunately we have already stored in the backbuffer's surface a rectangle of opaque content --- typically the bottommost ThebesLayer for the Web content. When our layer is being drawn over that rectangle, we can safely use subpixel AA.

Comment 48

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

I think this should be a softblocker, and I think we should take this patch for final.

Comment 49

[orangezilla]

(In reply to comment #46)
> Wanted to add that regarding the ESPN site, that the menu seemed to work like
> normal and didn't change the way the fonts looked when hovering over a menu
> when I did not have flash installed. As soon as I installed flash it's back to
> the normal behavior where it looks off, when hovering over a menu.
That is to be expected, see bug 637139 spinoff

(In reply to comment #48)
> I think this should be a softblocker, and I think we should take this patch for
> final.
Thanks for the patch Robert, I think it probably should be a softblocker as no doubt there are many more websites affected, and I believe a majority of FF4 users are expected to run without acceleration enabled- does the patch address all these issues, or specific spinoff bugs?:

Bug 637073 - Text is greyscale antialiased on certain websites with hardware acceleration off 

Bug 637081 - Text in the https secure verification link box is greyscale AA antialiased with hardware acceleration off 

Bug 637139 - Drop down menus overlapping flash content have text rendered in greyscale AA, hardware acceleration off 

Bug 637142 - Pop ups and overlayed text on youtube is greyscale AA antialiased 

The last bug I am wondering whether it should be a Tech Evangelism issue as it seems to be affecting all browsers that use some kind of hardware acceleration (WebGL in Chrome 9's case), so maybe an issue that youtube needs to fix itself, or Adobe?

Comment 50

[Joe Drew (not getting mail)]

orangezilla, I presume you didn't mean to reset those flags.

Comment 51

[orangezilla]

(In reply to comment #50)
> orangezilla, I presume you didn't mean to reset those flags.
No, seemed to happen when I posted, didn't make any changes or click save changes.

Comment 52

[Mike Beltzner [:beltzner, not reading bugmail]]

Please put this up for approval once we have a tested patch, include risk v. reward. Don't think this blocks the release based on roc's assertion that it shouldn't hard block.

Comment 53

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

Risk is very low. we're just changing whether subpixel AA is used or not, and it's pretty obvious that we're just adding some more cases where subpixel AA is used.

Reward is quite high. Text quality is a big issue for us and this bug affects many sites, and is a very visible regression from previous versions of Firefox and other browsers.

Comment 54

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 515583 [details] [diff] [review]
fix

a=beltzner

Comment 55

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/c1d77dbe4193

Calling this fixed. If there are still issues please file new bugs (if they aren't covered by one of the existing bugs).

Comment 56

[Timothy Nikkel (:tnikkel)]

We should test to see if any of the four bugs listed in comment 49 are fixed by this.

Comment 57

[Timothy Nikkel (:tnikkel)]

Fixed typo in reftest.list that caused it to fail
http://hg.mozilla.org/mozilla-central/rev/b758d7b3e139

Comment 58

[(no longer active)]

Landing of this bug and bug 635373 caused Windows reftest failures such as <http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1299024306.1299027792.9789.gz>.

I landed the following two changesets to deal with the failures:

http://hg.mozilla.org/mozilla-central/rev/f0a5657c643c
http://hg.mozilla.org/mozilla-central/rev/3436b367b4a4

Comment 59

[juan becerra [:juanb]]

orangezilla, could you help us check if the bugs in comment #49 are fixed by this?

Comment 60

[orangezilla]

(In reply to comment #59)
> orangezilla, could you help us check if the bugs in comment #49 are fixed by
> this?
Is there a build where the patch is applied you have a link to? I am not certain how to build myself.

Comment 61

[Emanuel Hoogeveen [:ehoogeveen]]

It should be in today's nightly.

Comment 62

[Asa Dotzler [:asa]]

This seems to have been accidentally reopened. Re-resolving.

Comment 63

[orangezilla]

(In reply to comment #59)
> orangezilla, could you help us check if the bugs in comment #49 are fixed by
> this?

Only one seems to be completely fixed, Bug 637073, others are not fixed or only partially fixed:

------------------------------------------
Bug 637081 - Text in the https secure verification link box is greyscale AA
antialiased with hardware acceleration off

not fixed, still greyscale antialiased

------------------------------------------
Bug 637139 - Drop down menus overlapping flash content have text rendered in
greyscale AA, hardware acceleration off 

With the espn site the text in the drop down menu does not drop to greyscale, but still drops to darker/duller anti aliasing when the drop down menu falls over flash content, it should not change and doesn't with plugin container off or acceleration on

With the samsung site the text is not greyscale anti aliased but it is still darker(or a duller colour?) antialiased than with plugin container off, should be the same 

--------------------------------------------
Bug 637142 - Pop ups and overlayed text on youtube is greyscale AA antialiased

not fixed, still greyscale antialiased

Comment 64

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

Bug 637081 and bug 637139 sound like the "manual Dwrite" text rendering gamma correction problem. Bas, do you have a bug for that?

Comment 65

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

And I suspect bug 637142 is about the text rendered by Flash itself, which is quite a different issue.

Comment 66

[orangezilla]

Reopened per comment 37, this is a tracker bug for the four bugs listed in comment 49, only one out of four is fixed per comment 63.

Comment 67

[Timothy Nikkel (:tnikkel)]

I don't think we need to keep this open if all the issues are covered by the other bugs filed. Especially since a patch landed in this bug that did fix some issues. Let's close this and avoid any confusion.

Comment 68

[orangezilla]

(In reply to comment #67)
> I don't think we need to keep this open if all the issues are covered by the
> other bugs filed. Especially since a patch landed in this bug that did fix some
> issues. Let's close this and avoid any confusion.
Fair enough, but can someone confirming the unresolved bugs, thanks.

Comment 69

[orangezilla]

Eh, sorry, everytime I post it is reopening the bug for the for some reason, resolving again.