926023 - grayscale aa instead of cleartype in Fx menus

Status: VERIFIED FIXED

(Core :: Graphics: Text, defect)

Description

[al_9x]

Attachment: zoomed in help menu

Fx 27.0a1 (2013-10-11)
xp sp3 (can be reproduces in a vm), no acceleration

Comment 2

[al_9x]

This is not the same as as bug 828192.

In bug 828192 - the cleartype colors are off on selected/hilighted menu items.

here - complete absence of cleartype on menu items (non highlighted)

Comment 3

[al_9x]

Last good nightly: 2013-09-20
First bad nightly: 2013-09-21

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f8a683dfc42&tochange=a2c31dc69ab3

Comment 4

[Dão Gottwald [:dao]]

Can you reproduce this with gfx.content.azure.enabled set to false?

Comment 5

[al_9x]

(In reply to Dão Gottwald [:dao] from comment #4)
> Can you reproduce this with gfx.content.azure.enabled set to false?

after setting and restarting, cleartype is back. Bug 812871/Bug 828192 is not affected.

Comment 6

[bhavana bajaj [:bajaj]]

Tracking and passing onto Matt given this is a fallout form 907926.

Comment 7

[Matt Woodrow (:mattwoodrow)]

I can't reproduce this on windows 7, so I guess it's specific to winxp. I don't have any winxp machines at the moment, do we have anyone else that could take a look at this?

Comment 8

[al_9x]

(In reply to Matt Woodrow (:mattwoodrow) from comment #7)
> I can't reproduce this on windows 7, so I guess it's specific to winxp. I
> don't have any winxp machines at the moment, do we have anyone else that
> could take a look at this?

a vm will do

Comment 9

[Matt Woodrow (:mattwoodrow)]

Milan, do we have anyone else with a WinXP dev env that could take a look at this?

I don't have winxp or vmware licenses, so it's fairly high overhead for me to get set up to debug it.

I don't imagine it will be particularly difficult to fix.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

Either BenWa or Bas should, but both are away-ish until next week.

Comment 11

[Bas Schouten (:bas.schouten)]

(In reply to Milan Sreckovic [:milan] from comment #10)
> Either BenWa or Bas should, but both are away-ish until next week.

I don't have a WinXP VM setup anymore. Matt, perhaps you can try switching Win7 into the classic theme and seeing if that reproduces it?

Comment 12

[Dão Gottwald [:dao]]

(In reply to Bas Schouten (:bas.schouten) from comment #11)
> (In reply to Milan Sreckovic [:milan] from comment #10)
> > Either BenWa or Bas should, but both are away-ish until next week.
> 
> I don't have a WinXP VM setup anymore. Matt, perhaps you can try switching
> Win7 into the classic theme and seeing if that reproduces it?

Or maybe Aero basic. You'd also want to disable Direct2D, I guess.

Comment 13

[al_9x]

please stop pretending that an xp vm is some sort of rare extinct beast, once gone, never to be seen again.

Since a significant % of Fx windows users are on xp (~40% according to one estimate in the platform thread) Mozilla should be providing you with vms and in fact insisting that font code be validated on xp before pushing.

But even if Mozilla is not helping, it's trivial to google up an xp vm solution

Here's one of many (extracting win7 xp mode vm for use with vmware player or virtualbox):
http://blog.zeltser.com/post/15781390680/windows-xp-mode-for-vmware-virtualization
http://www.howtogeek.com/howto/10911/
http://lifehacker.com/5965889/how-to-run-windows-xp-for-free-in-windows-8

Comment 14

[Matt Woodrow (:mattwoodrow)]

Attachment: Use the value of SetPermitSubpixelAA for DrawTargetCairo

Managed to reproduce this using Windows XP Mode.

Comment 15

[Matt Woodrow (:mattwoodrow)]

(In reply to al_9x from comment #13)
> please stop pretending that an xp vm is some sort of rare extinct beast,
> once gone, never to be seen again.
> 
> Since a significant % of Fx windows users are on xp (~40% according to one
> estimate in the platform thread) Mozilla should be providing you with vms
> and in fact insisting that font code be validated on xp before pushing.
> 
> But even if Mozilla is not helping, it's trivial to google up an xp vm
> solution
> 
> Here's one of many (extracting win7 xp mode vm for use with vmware player or
> virtualbox):
> http://blog.zeltser.com/post/15781390680/windows-xp-mode-for-vmware-
> virtualization
> http://www.howtogeek.com/howto/10911/
> http://lifehacker.com/5965889/how-to-run-windows-xp-for-free-in-windows-8

It's not a question of being able to obtain a windows xp vm, but of setting it up for development.

Setting up the tooling required for building, installing visual studio, downloading the source code, building all takes time. This work isn't a once off either, since the build requirements change fairly often.

Given that bugs that only occur on windows xp are exceedingly rare (at least in my experience), it's not surprising that most developers don't want to waste a day doing this.

Luckily in this case I was able to figure the problem out just by reading code, and just needed the VM to test.

Comment 16

[al_9x]

(In reply to Matt Woodrow (:mattwoodrow) from comment #15)
> 
> Setting up the tooling required for building, installing visual studio,
> downloading the source code, building all takes time. This work isn't a once
> off either, since the build requirements change fairly often.
> 
> Given that bugs that only occur on windows xp are exceedingly rare (at least
> in my experience), it's not surprising that most developers don't want to
> waste a day doing this.
> 

It would make sense for someone at mozilla to set up such a vm and make it available to whoever needs it.

> Luckily in this case I was able to figure the problem out just by reading
> code, and just needed the VM to test.

That's great, thanks.

There are two other bugs with cleartype in Fx chrome on xp (Bug 828073, Bug 828192 ( Jonathan Kew posted posted a regression window there: https://bugzilla.mozilla.org/show_bug.cgi?id=828192#c3 ) duped to Bug 812871)

Since you started on this, perhaps you could take a look, and at least ping the dev who should address them.

Comment 17

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c99d15a060e2

Comment 18

[Matt Woodrow (:mattwoodrow)]

Backed out for causing reftest failures: https://hg.mozilla.org/integration/mozilla-inbound/rev/ed57804472ee

https://tbpl.mozilla.org/php/getParsedLog.php?id=30120805&tree=Mozilla-Inbound&full=1

Comment 19

[al_9x]

(In reply to Matt Woodrow (:mattwoodrow) from comment #18)
> Backed out for causing reftest failures:

What does that mean?  Do the tests need fixing or the patch?  Are you planning to?

Comment 20

[Matt Woodrow (:mattwoodrow)]

Probably the patch. I'm working on it, yes.

Comment 21

[Matt Woodrow (:mattwoodrow)]

Attachment: Use the value of SetPermitSubpixelAA for DrawTargetCairo v2

This fixes the reftest failures for me locally, pushed it to try to confirm.

https://tbpl.mozilla.org/?tree=Try&rev=cd9667edb027

Comment 22

[Matt Woodrow (:mattwoodrow)]

Attachment: Use the value of SetPermitSubpixelAA for DrawTargetCairo v3

Comment 23

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e9370b4c4ace

Comment 24

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/e9370b4c4ace

Comment 25

[Matt Woodrow (:mattwoodrow)]

Comment on attachment 830587 [details] [diff] [review]
Use the value of SetPermitSubpixelAA for DrawTargetCairo v3

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 907926
User impact if declined: Missing subpixel AA on some text
Testing completed (on m-c, etc.): Been on m-c for over a week, tested manually on winxp vm.
Risk to taking this patch (and alternatives if risky): Very low risk.
String or IDL/UUID changes made by this patch: None

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/5ec49fda7a68

Comment 27

[u279076]

al_9x, can you please verify this is fixed in Firefox 27 and 28?

Comment 28

[u279076]

Given lack of response from the bug reporter this might not be verifiable. Flagging for verification to make an attempt.

Comment 29

[Ioana (away)]

Tested this on Windows XP SP3 with a Firefox 27.0a1 build with the bug and Firefox 27.0b7, both with hardware acceleration on and off. I see no difference between them.

Comment 30

[u279076]

Thanks for trying, Ioana. Back to the bug reporter to verify this is fixed. Tagging as [qa-] since this is unverifiable by QA.

Comment 31

[al_9x]

verified

Comment 32

[al_9x]

Attachment: Fx 33.1 build3

this regressed

Comment 33

[asdf123]

This bug *affected* Windows 7 (I took a capture: https://rbt.asia/boards/g/img/0378/07/1383554522992.png), and I can confirm the regression on this OS. URL bar started displaying grayscale AA again, and it isn't fixed by setting gfx.content.azure.enabled to false.

Please fix this.

Comment 34

[Timothy Nikkel (:tnikkel)]

Please file a new bug. Re-Opening up a year old bug that was fixed and then something else regressed will be confusing.

Comment 35

[al_9x]

Bug 1099443

Comment 36

[al_9x]

I created a new bug, is someone going to look at it?  Is it too much to ask for basic text rendering not to constantly regress?  The blurry gray-scale mess makes my eyes hurt, and this is from an app for which text rendering is its primary function.

Is Google paying you 300 million a year to make firefox unusable?  If you look at the results, that's exactly what's happening, money comes in, quality goes down, usability/features erode and Chrome market share surges.

Comment 37

[Milan Sreckovic [:milan] (needinfo for best results)]

With 200000 bugs getting filed per year, sometimes bugs get overlooked.  Thanks for filing the new one, that's the right way to get the attention.