Open Bug 629891 Opened 9 years ago Updated 3 years ago

Tooltip text rendered with grayscale anti-aliasing

Categories

(Core :: Graphics, defect)

x86
Windows 7
defect
Not set

Tracking

()

People

(Reporter: stanio, Assigned: tnikkel)

References

(Blocks 1 open bug)

Details

(Whiteboard: [approved-patches-landed][not-ready])

Attachments

(9 files)

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110129 SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre

Mouse over a browser tab or page element which has a 'title' attribute set and observe the tool-tip text - it is rendered with discolored ClearType edges making it look blurry.  Appears both with Direct2D and with Direct2D disabled.

Reproducible: Always
Attached image Internet Explorer 8
Happens on Windows XP, also.
Version: unspecified → Trunk
blocking2.0: --- → ?
I'm unable to reproduce with windows 7 nightly build from today. The title tips are anti-aliased with grayscale aa here and other than being grayscale aa, they look fine. D2D and DirectWrite both enabled. Intel graphics.
> The title tips are anti-aliased with grayscale aa here and other than being 
> grayscale aa, they look fine.

That's the actual issue I've opened - the text being rendered using grayscale AA, rather than using CrearType AA.  May be you see them look fine (enough) just because title tips are usually small and contain short text.  The quality of the text using grayscale AA however is suboptimal, as number of similar (same) issues regarding normal page content have been addressed already.
Confirming, updating summary, and copying a few awesome text handling people. 

I do not think we should block on this.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Tool-tip text rendered with discolored edges → Tool-tip text rendered with grayscale anti-aliasing
Attached patch patch for XPSplinter Review
Just as in bug 624452, on XP we get a null theme. I have no idea what happens on Windows Vista/7.
Attachment #512053 - Flags: review?(roc)
Attachment #512053 - Flags: approval2.0?
blocking2.0: ? → -
Assignee: nobody → tnikkel
Attachment #512053 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/1d9299a50242

I don't know if that will fix Windows 7/Vista, so if someone could test in tomorrows nightly (2011-02-16), that would be great.
Duplicate of this bug: 630093
(In reply to comment #9)
> http://hg.mozilla.org/mozilla-central/rev/1d9299a50242
> 
> I don't know if that will fix Windows 7/Vista, so if someone could test in
> tomorrows nightly (2011-02-16), that would be great.

Didn't help, still shows greyscale AA.
In about:buildconfig what does it say beside "Built from"? I ask because tinderbox builds with this patch have just showed up minutes ago.
That's the one I installed, I was waiting for it. ;)

It shows your commit 1d9299a50242.
Well then Windows Vista/7 will need a different fix, I can't really debug under either right now.
Using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110216 Firefox/4.0b12pre, the issue appears fixed for me on Win 7 - Windows Classic theme.  I haven't really tried it with Aero theme, even when opening this report.
I can confirm the issue is still present with Win7 Aero theme.
Whiteboard: [approved-patches-landed]
Whiteboard: [approved-patches-landed] → [approved-patches-landed][not-ready]
I can still confirm this with Firefox 5 beta and 6 aurora on Win7 with D2D enabled.

This might be a regression as I believe to remember that tooltips became sub-pixel AAed at some point in the beta phase of Firefox 4.
Same here, Win7 x64, Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110619 Firefox/7.0a1.

Since 4.0 release it is broken. I also confirm that D2D option doesn't have an effect, grayscale antialiasing is used even with D2D disabled.

Tooltips over tab headers, images, links are rendered with grayscale anti-aliasing.

Also tooltips don't have shadows like in 3.6.
> Also tooltips don't have shadows like in 3.6.

I mean in FF 3.6 tooltips do have shadows while in FF 4 they don't. They don't have shadows in the latest nightly either.
The loss of shadows could be due to bug 603793.
This bug is still present in Firefox 5 (stable). There are several places were I saw Firefox 5 use greyscale-aa under Windows 7 (with Aero enabled).

Actually this bug applies to:
- tooltip texts
- the tooltip shown in the lower left when hovering over links
- adress bar
- search bar
- fonts on tabs (not always though, I'm not sure what's the reason yet)
- some dropdown lists on websites

This bug is quite annoying and makes the move to DirectDraw font rendering even more unappealing.
(In reply to comment #21)
> - some dropdown lists on websites

Please file a bug with an example site that has this problem.
Someone on irc reported context menus having this issue as well:  http://i.imgur.com/H5ixM.png
I added an attachment were you can see all places were greyscale anti aliasing is used instead of subpixel anti aliasing (Though I couldn't find an example for a dropdown box yet).

I was able to reproduce the problem with a clean profile. Steps to reproduce:
- tooltip texts: simply hover mouse over an element that has a tooltip, e.g. the "flags"-sections of a bug entry on bugzilla.mozilla.org (not visible in the attachment but verified by me on the same page).
- the tooltip shown in the lower left when hovering over links: just hover over a link (see attachment)
- adress bar: set "Tabs on Top" to false. Nothing else needed to do (see attachment)
- search bar: set "Tabs on Top" to false. Nothing else needed to do (see attachment)
- fonts on tabs: visit https://bugzilla.mozilla.org and activate this tab, then all tabs will use greyscale anti aliasing (see attachment). On other pages, e.g. a blank page correct subpixel anti aliasing is used, though.
I also found an example for greyscale anti aliasing in a dropdown list (see attachment).

The problem is quite abit confusing, since the text is re-rendered after about five seconds with subpixel anti aliasing.

Steps to reproduce:
- open https://www.google.com/accounts/NewAccount
- expand the dropdown list for "location" ("Standort" in German)
- when you scroll in the list it is first rendered with grayscale anti aliasing and re-rendered with subpixel anti aliasing after about five seconds.

I'll keep you updated if I find another example.
Most of comment 24 and all of comment 25 is about different, already known, issues. This bug is strictly about tool-tip text, which is still greyscale, even in Nightly.
Duplicate of this bug: 659211
Summary: Tool-tip text rendered with grayscale anti-aliasing → Tooltip text rendered with grayscale anti-aliasing
Any progress on this? Bug is still present as of Firefox 32.0.3
Regression-range:

Last good revision: d5e211bdd793 (2010-08-13)
First bad revision: 656d99ca089c (2010-08-14)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d5e211bdd793&tochange=656d99ca089c


With gfx.font_rendering.directwrite.enabled;true set:

Last good revision: b84d0be52070 (2010-06-10)
First bad revision: 431eab8cf6ab (2010-06-11)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b84d0be52070&tochange=431eab8cf6ab
Can you still reproduce the issue in latest stable Firefox version or in latest Nightly?
Flags: needinfo?(stanio)
Firefox ESR 45.4, grayscale anti-aliasing is here. Win 7.
Same here with 20161001 nightly
I was thinking that it could be fixed by recent fixes in Nightly, like enabling by default Skia backend or fixing subpixel antialiasing.

Could you please attach here as attachment your complete information from about:support from Nightly?
Flags: needinfo?(mrpastorm)
I still see the problem with Firefox 49 and current Firefox Developer Edition (51.0a2) on Windows 10 64-bit, although I'm not really noticing it (w/o zooming pixels in) on a high-dpi screen now.
Flags: needinfo?(stanio)
Could you please attach here as attachment your complete information from about:support from Nightly?
Flags: needinfo?(stanio)
Note, I have not tried Nightly explicitly previously as someone else already done it and has attached about:support data.  I've now tried it using fresh new profile, observed the issue is still there, and I'm attaching my data which might not differ significantly from attachment 8797224 [details].
Flags: needinfo?(stanio)
You need to log in before you can comment on or make changes to this bug.