Closed Bug 1315568 Opened 8 years ago Closed 8 years ago

Awful blurry fonts in text in some places after landing patch from bug #1314133

Categories

(Core :: Graphics: Text, defect, P3)

Product:
Core
Component:
Graphics: Text
Version:
52 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla53
Tracking Flags:
Tracking Status
firefox49 --- unaffected
firefox-esr45 --- unaffected
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 --- verified
firefox53 - verified

People

(Reporter: Virtual, Assigned: mchang)

References

Details

(Keywords: access, nightly-community, regression, Whiteboard: [gfx-noted])

Attachments

(32 files, 3 obsolete files)

blurry fonts 1.png
147.24 KB, image/png
Details
sharp fonts 1.png
140.64 KB, image/png
Details
blurry fonts 2.png
151.59 KB, image/png
Details
sharp fonts 2.png
144.11 KB, image/png
Details
Graphic section from about:support (bug).txt
1.51 KB, text/plain
Details
Graphic section from about:support (no bug).txt
1.54 KB, text/plain
Details
layers.gpu-process.dev.enabled = false + gfx.direct2d.disabled = false.png
177.09 KB, image/png
Details
layers.gpu-process.dev.enabled = true + gfx.direct2d.disabled = false.png
180.74 KB, image/png
Details
layers.gpu-process.dev.enabled = false + gfx.direct2d.disabled = true.png
215.53 KB, image/png
Details
layers.gpu-process.dev.enabled = true + gfx.direct2d.disabled = true.png
215.52 KB, image/png
Details
Graphic section from about:support with gfx.direct2d.disabled = true.txt
1.61 KB, text/plain
Details
Graphic section from about:support with gfx.content.azure.backends = direct2d1.1,cairo.txt
1.51 KB, text/plain
Details
gfx.content.azure.backends = direct2d1.1,cairo 1.png
146.03 KB, image/png
Details
gfx.content.azure.backends = direct2d1.1,cairo 2.png
148.03 KB, image/png
Details
Firefox 52.0a1 (2016-11-09).png
79.17 KB, image/png
Details
SeaMonkey 2.40.png
72.30 KB, image/png
Details
Chrome 54.0.2840.87.png
111.83 KB, image/png
Details
Vivaldi 1.4.589.38.png
111.26 KB, image/png
Details
Opera 41.0.2353.56.png
116.65 KB, image/png
Details
blurry fonts 3.png
135.71 KB, image/png
Details
sharp fonts 3.png
105.88 KB, image/png
Details
1a - ac3c50d5f361cf011f770867866fa51bf921484f.png
263.49 KB, image/png
Details
1b - ac3c50d5f361cf011f770867866fa51bf921484f.png
89.04 KB, image/png
Details
2a - 785c25e199a5a83a5969cf7834136f53a77120ff.png
262.96 KB, image/png
Details
2b - 785c25e199a5a83a5969cf7834136f53a77120ff.png
88.99 KB, image/png
Details
3a - 4041c79947120e0ef449544e715e3732cf82b6ee.png
263.39 KB, image/png
Details
3b - 4041c79947120e0ef449544e715e3732cf82b6ee.png
89.05 KB, image/png
Details
4a - GPU Process disabled.png
262.98 KB, image/png
Details
4b - GPU Process disabled.png
89.74 KB, image/png
Details
5a - default.png
267.39 KB, image/png
Details
5b - default.png
95.18 KB, image/png
Details
Use Force GDI information from SkTypeface
4.54 KB, patch
lsalzman
: review+
jcristau
: approval-mozilla-aurora+
Details | Diff | Splinter Review
[Tracking Requested - why for this release]: Regression Regression window pushlog (mozilla-inbound): https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c04f84afb1bd6b3ea372164012735de6c8f2d582&tochange=b4ade2b0841c5825968f34752d86ee09507a0a9f Workaround: set "layers.gpu-process.dev.enabled" to "false" in about:config
Flags: needinfo?(dvander)
Comment on attachment 8808003 [details] Graphic section from about:support (no bug).txt and per bug #1315540 comment #4 in this bug attachment in comment 5 report only bad values
Attachment #8808003 - Attachment description: Graphic section from about;support (no bug).txt → Graphic section from about:support (no bug).txt
STR: Just see address bar, select dropdown menu or tooltip. Other things could also be affected.
Has Regression Range: --- → yes
Has STR: --- → yes
If you enable the GPU process, but disable direct2d, do your fonts look blurry?
Flags: needinfo?(dvander) → needinfo?(virtual)
Also, how do the fonts look in Chrome? Thanks!
Sorry, can you also set the preference "gfx.content.azure.backends" to "direct2d1.1,cairo", restart, and also see if that's any different for you?
@comment 9: I don't know how to do that because if I set HA off, then I don't get the GPU Process. @comment 10: I (and I believe others too) don't like the way fonts look in Chrome (IE is better). @comment 11: that fixes it - but other bug shows up: bold letters get VERY fat.
GPU process disabled + Direct2D disabled = bug + some other issue... as all fonts in text on whole page are blurry
GPU process enabled + Direct2D disabled = bug + some other issue... as all fonts in text on whole page are blurry
(In reply to David Anderson [:dvander] from comment #9) > If you enable the GPU process, but disable direct2d, do your fonts look > blurry? Yes. What's more disabling Direct2D makes all fonts in text on whole pages... so looks I found another bug.
(In reply to Mason Chang [:mchang] from comment #10) > Also, how do the fonts look in Chrome? Thanks! I'm using Firefox browser, not Chrome one. I don't understand what's Chrome have to do with Firefox bug. More Chromification or what? ;) (In reply to Mason Chang [:mchang] from comment #11) > Sorry, can you also set the preference "gfx.content.azure.backends" to > "direct2d1.1,cairo", restart, and also see if that's any different for you? Yes. There are differences, all fonts in text on whole pages looks better, but fonts in text in address toolbar are blurry and fonts in text in tab titles looks kinda oversharpen (probably it's because of usage grayscale antialiasing method, so looks I found next bug) additionally tooltip have other height.
(In reply to Guilherme Lima from comment #12) > @comment 9: I don't know how to do that because if I set HA off, then I > don't get the GPU Process. Just set "gfx.direct2d.disabled" to "true" in about:config (In reply to Guilherme Lima from comment #12) > @comment 10: I (and I believe others too) don't like the way fonts look in > Chrome (IE is better). I agree, they look blurry and no sharp. Maybe they using grayscale antialiasing insted of using subpixel antialiasing or maybe other bugs, who knows, but it should matters us naught. (In reply to Guilherme Lima from comment #12) > @comment 11: that fixes it - but other bug shows up: bold letters get VERY > fat. In my case it fixes in only on all fonts in text on whole pages, but fonts in text in address toolbar and in tabs titles are still affected. I'm not experiencing very fat bold letters here.
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #24) > (In reply to Mason Chang [:mchang] from comment #10) > > Also, how do the fonts look in Chrome? Thanks! > > I'm using Firefox browser, not Chrome one. > I don't understand what's Chrome have to do with Firefox bug. > More Chromification or what? ;) Thanks! Yes, can you please try the same sites in Chrome and see if the font is equivalent for you. What happens without D2D is that we use Skia to render content. Skia is used by Chrome as their rendering backend as well, which means our fonts will look roughly equal to Chrome. If a user has acceleration disabled (d2d disabled), they would fall back to Cairo and use GDI fonts instead of dwrite fonts (which is only supported in D2D. From comment 24, this isn't a bug, but different font backend). With the GPU process, we disabled acceleration in the UI process so that if the GPU fails, the whole browser doesn't crash. This means we use a different backend for the UI process, and some fonts will look different. I'm just trying to make sure this isn't a different bug versus the expected result, which is fonts should look roughly equal to Chrome for some UI things.
Flags: needinfo?(virtual)
(In reply to Mason Chang [:mchang] from comment #26) > see if the font is equivalent for you No, fonts in text are blurrier and less sharper in tootips on Mozilla Firefox. Dropdown menu is also probably affected, but I can't tell due to UX and e10s team made font smaller, made dropdown text with other font family than on button and increased that much space between items... :/ (see bug #1313418). (In reply to Mason Chang [:mchang] from comment #26) > What happens without D2D is that we use Skia to > render content. Skia is used by Chrome as their rendering backend as well, > which means our fonts will look roughly equal to Chrome. So we should do everything to fix this blurry fonts in text, even if this will mean tweaking, patching and fixing Skia. (In reply to Mason Chang [:mchang] from comment #26) > If a user has acceleration disabled (d2d disabled), they would fall back to > Cairo and use GDI fonts instead of dwrite fonts (which is only supported in > D2D. From comment 24, this isn't a bug, but different font backend). With > the GPU process, we disabled acceleration in the UI process so that if the > GPU fails, the whole browser doesn't crash. This means we use a different > backend for the UI process, and some fonts will look different. I'm just > trying to make sure this isn't a different bug versus the expected result, > which is fonts should look roughly equal to Chrome for some UI things. Thank you very much for detailed explanation. It was very informative. Unfortunately, most of users won't be caring about technical details. They will see that fonts in text are rendered blurry and no sharp. I know that stability of the product is primary, but that thing isn't allowed to break other things, especially the clearance and visibility of fonts in text.
(In reply to Virtual_ManPL [:Virtual] - (ni? me) from comment #32) > (In reply to Mason Chang [:mchang] from comment #26) > > see if the font is equivalent for you > No, fonts in text are blurrier and less sharper in tootips on Mozilla > Firefox. Dropdown menu is also probably affected, but I can't tell due to UX > and e10s team made font smaller, made dropdown text with other font family > than on button and increased that much space between items... :/ (see bug > #1313418). > Sorry, are the dropdown fonts in nightly equivalent to chrome, not equivalent to old firefox. > (In reply to Mason Chang [:mchang] from comment #26) > > What happens without D2D is that we use Skia to > > render content. Skia is used by Chrome as their rendering backend as well, > > which means our fonts will look roughly equal to Chrome. > So we should do everything to fix this blurry fonts in text, even if this > will mean tweaking, patching and fixing Skia. We tried as best we could, but without actually using d2d, it's not practical to get equivalent fonts. We're already using dwrite fonts instead of GDI Fonts (which is what Cairo was using). We tweaked Skia to move their fonts closer to what we have with D2D, but there's no real way to get exactly equal. > > (In reply to Mason Chang [:mchang] from comment #26) > > If a user has acceleration disabled (d2d disabled), they would fall back to > > Cairo and use GDI fonts instead of dwrite fonts (which is only supported in > > D2D. From comment 24, this isn't a bug, but different font backend). With > > the GPU process, we disabled acceleration in the UI process so that if the > > GPU fails, the whole browser doesn't crash. This means we use a different > > backend for the UI process, and some fonts will look different. I'm just > > trying to make sure this isn't a different bug versus the expected result, > > which is fonts should look roughly equal to Chrome for some UI things. > > Thank you very much for detailed explanation. It was very informative. > Unfortunately, most of users won't be caring about technical details. > They will see that fonts in text are rendered blurry and no sharp. > I know that stability of the product is primary, but that thing isn't > allowed to break other things, especially the clearance and visibility of > fonts in text. I'm not really sure what we can do here. D2D fonts look different than Cairo fonts than Skia fonts. I agree with you, it'd be great if things were equal with D2D. However, the fonts in Chrome are shipping to most Windows users due to market share. If the fonts are roughly equivalent to Chrome, I don't most users would really dislike them, otherwise Chrome wouldn't have such market share either. I'm sorry, I understand you'd like fonts to be the same. We would too! But I'm not quite sure how we can do that. Even if we kept Cairo instead of Skia, fonts wouldn't be the same as well, as your screenshots have shown.
and Library is affected... :/ Maddens for me. (In reply to Mason Chang [:mchang] from comment #33) > Sorry, are the dropdown fonts in nightly equivalent to chrome, not > equivalent to old firefox. Could be, I'm unable to tell properly like I said due to UX and e10s team made font smaller, made dropdown text with other font family than on button and increased that much space between items... :/ (see bug #1313418) Blurry and not sharp font in text on tootip is still valid. (In reply to Mason Chang [:mchang] from comment #33) > We tried as best we could, but without actually using d2d, > [...] > We're already using dwrite fonts instead > of GDI Fonts (which is what Cairo was using). We tweaked Skia to move their > fonts closer to what we have with D2D, but there's no real way to get > exactly equal. > [...] > I'm not really sure what we can do here. D2D fonts look different than Cairo > fonts than Skia fonts. I agree with you, it'd be great if things were equal > with D2D. So maybe not the hardest ;) Can't we just simply use more instances of D2D in every process like system do? So it will work like before instead of using different methods for every processes. (In reply to Mason Chang [:mchang] from comment #33) > it's not practical to get equivalent fonts. For my eyes with hyperopia, yes it is, even it have to. > > (In reply to Mason Chang [:mchang] from comment #26) > However, the fonts in Chrome are shipping to most Windows users > due to market share. If the fonts are roughly equivalent to Chrome Maybe... but if something is bad and still many users using it, it's not good argument to also use it. > > (In reply to Mason Chang [:mchang] from comment #26) > most users would really dislike them, otherwise Chrome wouldn't have such > market share either. I don't think they like Chrome because of font rendering, it was because of snappy, performance, ram usage, pushed with every software and with Google search etc. > > (In reply to Mason Chang [:mchang] from comment #26) > I'm sorry, I understand you'd like fonts to be the > same. We would too! But I'm not quite sure how we can do that. Even if we > kept Cairo instead of Skia, fonts wouldn't be the same as well, as your > screenshots have shown. Looks like I will need to fully disable GPU Process because of this, and maybe disable e10s in the feature, if you will plan to remove option to disable GPU Process. I'm only hoping that I won't have to look for another browser. At least there's always SeaMonkey without this issues. ;) Am I the only one which finding this font rendering mothod unacceptable because of blurriness and non sharpness?
I agree, the fonts look much worse than before. They look better (like IE/Edge) with the GPU process off. This would have to be a deal breaker for some, I'd rather skip the GPU process than have ugly font rendering like Chrome because I don't have driver instability or crashes anyways.
Until we figure out if we can do something: The gpu process pref isn't going away, it's fine to turn it off. That also gives us feedback as to how many people are disabling it.
Priority: -- → P3
Whiteboard: [gfx-noted]
(In reply to David Anderson [:dvander] from comment #38) > Until we figure out if we can do something I will also report it on Chrome/Chromium/Skia bug tracker and attach my report here. Maybe they will fix it on their side, to unload ours, as their font rendering in different and inconsistent compared to internal Windows system one, Internet Explorer, Microsoft Edge and Firefox. (In reply to David Anderson [:dvander] from comment #38) > The gpu process pref isn't going away, it's fine to turn it off. Thank you very much! \o/ (In reply to David Anderson [:dvander] from comment #38) > That also gives us feedback as to how many people are disabling it. I'm still using it, to find more bugs and issues, as Nightly tester ;)
> So maybe not the hardest ;) > Can't we just simply use more instances of D2D in every process like system > do? > So it will work like before instead of using different methods for every > processes. Not really. We'll use D2D for content processes but not the UI process. The biggest point about the GPU process is to prevent crashes due to hardware acceleration. If we didn't do that, then a GPU bug could crash the browser :(.
about:support from the user affected by the same issue in the duplicate: Graphics Features Compositing Direct3D 11 Asynchronous Pan/Zoom wheel input enabled; touch input enabled WebGL Renderer Google Inc. -- ANGLE (NVIDIA GeForce GT 630 Direct3D11 vs_5_0 ps_5_0) WebGL2 Renderer Google Inc. -- ANGLE (NVIDIA GeForce GT 630 Direct3D11 vs_5_0 ps_5_0) Hardware H264 Decoding Yes; Using D3D11 API Audio Backend wasapi Direct2D true DirectWrite true (6.3.9600.17111) GPU #1 Active Yes Description NVIDIA GeForce GT 630 Vendor ID 0x10de Device ID 0x1284 Driver Version 21.21.13.7570 Driver Date 10-25-2016 Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Subsys ID 130819da RAM 1024 Diagnostics AzureCanvasAccelerated 0 AzureCanvasBackend direct2d 1.1 AzureContentBackend direct2d 1.1 AzureFallbackCanvasBackend cairo Decision Log HW_COMPOSITING force_enabled by user: Force-enabled by pref D3D9_COMPOSITING disabled by default: Disabled by default force_enabled by user: Hardware compositing is force-enabled
The GPU process is Nightly-only IIUC (though I believe the hope is that it'll ride the 53 train).
status-firefox52: affected → disabled
tracking-firefox52: ? → ---
(In reply to Mason Chang [:mchang] from comment #40) > > So maybe not the hardest ;) > > Can't we just simply use more instances of D2D in every process like system > > do? > > So it will work like before instead of using different methods for every > > processes. > > Not really. We'll use D2D for content processes but not the UI process. The > biggest point about the GPU process is to prevent crashes due to hardware > acceleration. If we didn't do that, then a GPU bug could crash the browser > :(. So can the UI use plain old GDI rendering, with hinting ? It was much sharper IIRC. But currently there are several places (tooltips, inactive window tab titles, ...), where grayscale AA is used, without strong hinting. Perhaps it will be much better if they are fixed (enabling subpixel AA, or keeping grayscale AA but applying strong "GDI classic" like hinting).
Assignee: nobody → mchang
I think I may have a fix, can you try either of these builds to see if it fixes it for you: https://archive.mozilla.org/pub/firefox/try-builds/mchang@mozilla.com-ac3c50d5f361cf011f770867866fa51bf921484f/ https://archive.mozilla.org/pub/firefox/try-builds/mchang@mozilla.com-785c25e199a5a83a5969cf7834136f53a77120ff/ - This one should be ready in 2-3 hours.
Flags: needinfo?(virtual)
The main problem was that for some fonts, we'd like to force a GDI backwards compatible rendering mode with DWwrite fonts. I thought I fixed this in bug 1299903, but that only fixes it for fonts that specifically use bitmap fonts. In other cases such as Arial, a bitmap font doesn't exist and so the added code from bug 1299903 gets reverted and Skia stops using the GDI rendering params. This code adds a new SkPaint and SkScalerContext flag to force GDI rendering params. I'll try to upstream this too. [1] http://searchfox.org/mozilla-central/source/modules/libpref/init/all.js#3414 [2] http://searchfox.org/mozilla-central/source/gfx/skia/skia/src/ports/SkScalerContext_win_dw.cpp#743
Attachment #8812993 - Flags: review?(lsalzman)
screenshot a: 1a - ac3c50d5f361cf011f770867866fa51bf921484f = oversharpy address bar and less blurry toolip 2a - 785c25e199a5a83a5969cf7834136f53a77120ff = less blurry toolip 3a - 4041c79947120e0ef449544e715e3732cf82b6ee = less blurry toolip 4a - GPU Process disabled = without bug 5a - default = blurry and oversharpy fonts in tab & address bar and tooltip & URL tooltip screenshot b: 1b - ac3c50d5f361cf011f770867866fa51bf921484f = oversharpy fonts in Bookmarks in Library 2b - 785c25e199a5a83a5969cf7834136f53a77120ff = like without bug (expand expand button, but fonts are priority) 3b - 4041c79947120e0ef449544e715e3732cf82b6ee = like without bug (expand expand button, but fonts are priority) 4b - GPU Process disabled = without bug 5b - default = blurry and oversharpy fonts in Bookmarks in Library Thank you very much! Looks like we're going in the right direction, as only tooltip needs some tweaking to be less blurry and more sharpy like with GPU Process disabled.
Attachment #8812993 - Attachment is obsolete: true
Attachment #8812993 - Flags: review?(lsalzman)
Attachment #8815098 - Flags: review?(lsalzman)
Attachment #8815098 - Flags: review?(lsalzman) → review+
Pushed by mchang@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/0a18b6782086 Use Force GDI information from SkTypeface for GDI rendering modes in skia. r=lsalzman
https://hg.mozilla.org/mozilla-central/rev/0a18b6782086
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Tracking 53- as this is now resolved fixed.
tracking-firefox53: ? → -
Can you please verify the fix works on Nightly for you (not sure it made it to today's)? Also, if you see other places where the text isn't quite right, please file a new bug. Thanks!
Flags: needinfo?(virtual)
Comment on attachment 8815098 [details] [diff] [review] Use Force GDI information from SkTypeface Approval Request Comment [Feature/Bug causing the regression]: Skia on Windows, bug 1007702 [User impact if declined]: Some fonts will not look the same as before Skia content. [Is this code covered by automated tests?]: Yes [Has the fix been verified in Nightly?]: Yes [Needs manual test from QE? If yes, steps to reproduce]: No [List of other uplifts needed for the feature/fix]: None [Is the change risky?]: No [Why is the change risky/not risky?]: This just sets a flag that tells Skia to render the fonts with GDI compatible rendering options. [String changes made/needed]: None
Attachment #8815098 - Flags: approval-mozilla-aurora?
(In reply to Mason Chang [:mchang] from comment #65) > Can you please verify the fix works on Nightly for you (not sure it made it > to today's)? > > Also, if you see other places where the text isn't quite right, please file > a new bug. Thanks! Thank you very much! Looks mostly fixed. I will create follow up to fix leftovers.
Status: RESOLVED → VERIFIED
status-firefox53: fixed → verified
Flags: needinfo?(virtual)
(In reply to Mason Chang [:mchang] from comment #66) > Comment on attachment 8815098 [details] [diff] [review] > Use Force GDI information from SkTypeface > > Approval Request Comment > [Feature/Bug causing the regression]: Skia on Windows, bug 1007702 comment 43 suggests this doesn't affect 52 because the gpu process isn't enabled, can you clarify the status and why this uplift is needed anyway?
Flags: needinfo?(mchang)
(In reply to Julien Cristau [:jcristau] from comment #68) > (In reply to Mason Chang [:mchang] from comment #66) > > Comment on attachment 8815098 [details] [diff] [review] > > Use Force GDI information from SkTypeface > > > > Approval Request Comment > > [Feature/Bug causing the regression]: Skia on Windows, bug 1007702 > > comment 43 suggests this doesn't affect 52 because the gpu process isn't > enabled, can you clarify the status and why this uplift is needed anyway? That is true only because the bug here affected users who would normally be on d2d and have hardware acceleration. Users without hardware acceleration will use skia, which is bug 1007702 and still see the difference. It just means we haven't had a bug reporter about that specifically yet.
Flags: needinfo?(mchang)
Comment on attachment 8815098 [details] [diff] [review] Use Force GDI information from SkTypeface font rendering fix for aurora52
Attachment #8815098 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Fonts are still blurry with the gpu process. Tab titles and tooltips still look much better with layers.gpu-process.dev.enabled = false.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: