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

VERIFIED FIXED in Firefox 52

Status

()

Core
Graphics: Text
P3
major
VERIFIED FIXED
10 months ago
26 days ago

People

(Reporter: Virtual, Assigned: mchang)

Tracking

({access, nightly-community, regression})

52 Branch
mozilla53
x86_64
Windows 7
access, nightly-community, regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox49 unaffected, firefox-esr45 unaffected, firefox50 unaffected, firefox51 unaffected, firefox52 verified, firefox53- verified)

Details

(Whiteboard: [gfx-noted])

Attachments

(32 attachments, 3 obsolete attachments)

147.24 KB, image/png
Details
140.64 KB, image/png
Details
151.59 KB, image/png
Details
144.11 KB, image/png
Details
1.51 KB, text/plain
Details
1.54 KB, text/plain
Details
177.09 KB, image/png
Details
180.74 KB, image/png
Details
215.53 KB, image/png
Details
215.52 KB, image/png
Details
1.61 KB, text/plain
Details
1.51 KB, text/plain
Details
146.03 KB, image/png
Details
148.03 KB, image/png
Details
79.17 KB, image/png
Details
72.30 KB, image/png
Details
111.83 KB, image/png
Details
111.26 KB, image/png
Details
116.65 KB, image/png
Details
135.71 KB, image/png
Details
105.88 KB, image/png
Details
263.49 KB, image/png
Details
89.04 KB, image/png
Details
262.96 KB, image/png
Details
88.99 KB, image/png
Details
263.39 KB, image/png
Details
89.05 KB, image/png
Details
262.98 KB, image/png
Details
89.74 KB, image/png
Details
267.39 KB, image/png
Details
95.18 KB, image/png
Details
4.54 KB, patch
lsalzman
: review+
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)
Created attachment 8807998 [details]
blurry fonts 1.png
Created attachment 8807999 [details]
sharp fonts 1.png
Created attachment 8808000 [details]
blurry fonts 2.png
Created attachment 8808001 [details]
sharp fonts 2.png
Created attachment 8808002 [details]
Graphic section from about:support (bug).txt
Created attachment 8808003 [details]
Graphic section from about:support (no bug).txt
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)

Updated

10 months ago
status-firefox49: --- → unaffected
status-firefox50: --- → unaffected
(Assignee)

Comment 10

10 months ago
Also, how do the fonts look in Chrome? Thanks!
(Assignee)

Comment 11

10 months ago
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 12

10 months ago
@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.
status-firefox-esr45: --- → unaffected
Flags: needinfo?(virtual)
Created attachment 8808510 [details]
layers.gpu-process.dev.enabled = false + gfx.direct2d.disabled = false.png

GPU process disabled + Direct2D enabled = no bug
Created attachment 8808511 [details]
layers.gpu-process.dev.enabled = true + gfx.direct2d.disabled = false.png

GPU process enabled + Direct2D enabled = bug
Created attachment 8808512 [details]
layers.gpu-process.dev.enabled = false + gfx.direct2d.disabled = true.png

GPU process disabled + Direct2D disabled = bug
+ some other issue... as all fonts in text on whole page are blurry
Created attachment 8808513 [details]
layers.gpu-process.dev.enabled = true + gfx.direct2d.disabled = true.png

GPU process enabled + Direct2D disabled = bug
+ some other issue... as all fonts in text on whole page are blurry
Created attachment 8808515 [details]
Graphic section from about:support with gfx.direct2d.disabled = true.txt
(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.
Created attachment 8808518 [details]
Graphic section from about:support with gfx.content.azure.backends = direct2d1.1,cairo.txt
Created attachment 8808521 [details]
gfx.content.azure.backends = direct2d1.1,cairo 1.png
Attachment #8808516 - Attachment is obsolete: true
Created attachment 8808522 [details]
gfx.content.azure.backends = direct2d1.1,cairo 2.png
Attachment #8808517 - Attachment is obsolete: true
(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.
(Assignee)

Comment 26

10 months ago
(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)
Created attachment 8809100 [details]
Firefox 52.0a1 (2016-11-09).png
Flags: needinfo?(virtual)
Created attachment 8809101 [details]
SeaMonkey 2.40.png
Created attachment 8809102 [details]
Chrome 54.0.2840.87.png
Created attachment 8809103 [details]
Vivaldi 1.4.589.38.png
Created attachment 8809104 [details]
Opera 41.0.2353.56.png
(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.
(Assignee)

Comment 33

10 months ago
(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.
Created attachment 8809455 [details]
blurry fonts 3.png
Created attachment 8809456 [details]
sharp fonts 3.png
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?

Comment 37

10 months ago
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 ;)
(Assignee)

Comment 40

10 months ago
> 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 :(.

Updated

9 months ago
Duplicate of this bug: 1317144

Comment 42

9 months ago
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
status-firefox53: --- → affected
tracking-firefox53: --- → ?
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: ? → ---

Comment 44

9 months ago
(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)

Updated

9 months ago
Assignee: nobody → mchang
(Assignee)

Comment 45

9 months ago
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)
(Assignee)

Comment 46

9 months ago
Created attachment 8812993 [details] [diff] [review]
Add a Force GDI Mode flag to SkScalerContext and SkPaint

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)
(Assignee)

Comment 47

9 months ago
Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=bf283868b3a8568235ab96548fdefad7b60fa63a
(Assignee)

Comment 48

9 months ago
Sorry, bad try push. Real try push - https://treeherder.mozilla.org/#/jobs?repo=try&revision=4041c79947120e0ef449544e715e3732cf82b6ee
Created attachment 8813185 [details]
1a - ac3c50d5f361cf011f770867866fa51bf921484f.png
Flags: needinfo?(virtual)
Created attachment 8813187 [details]
1b - ac3c50d5f361cf011f770867866fa51bf921484f.png
Created attachment 8813188 [details]
2a - 785c25e199a5a83a5969cf7834136f53a77120ff.png
Created attachment 8813189 [details]
2b - 785c25e199a5a83a5969cf7834136f53a77120ff.png
Created attachment 8813190 [details]
3a - 4041c79947120e0ef449544e715e3732cf82b6ee.png
Created attachment 8813191 [details]
3b - 4041c79947120e0ef449544e715e3732cf82b6ee.png
Created attachment 8813192 [details]
4a - GPU Process disabled.png
Created attachment 8813193 [details]
4b - GPU Process disabled.png
Created attachment 8813195 [details]
5a - default.png
Created attachment 8813196 [details]
5b - default.png
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.
(Assignee)

Comment 60

9 months ago
Created attachment 8815098 [details] [diff] [review]
Use Force GDI information from SkTypeface
Attachment #8812993 - Attachment is obsolete: true
Attachment #8812993 - Flags: review?(lsalzman)
Attachment #8815098 - Flags: review?(lsalzman)

Updated

9 months ago
Attachment #8815098 - Flags: review?(lsalzman) → review+
(Assignee)

Comment 61

9 months ago
Try looks good - https://hg.mozilla.org/try/rev/fd715a04f00d6cdb79826f157efe76f09c57186d

Comment 62

9 months ago
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

Comment 63

9 months ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/0a18b6782086
Status: NEW → RESOLVED
Last Resolved: 9 months ago
status-firefox53: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla53
Tracking 53- as this is now resolved fixed.
tracking-firefox53: ? → -
(Assignee)

Comment 65

9 months ago
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)
(Assignee)

Comment 66

9 months ago
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)
(Assignee)

Comment 69

9 months ago
(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+

Comment 71

9 months ago
bugherderuplift
https://hg.mozilla.org/releases/mozilla-aurora/rev/2273338be470
Blocks: 1007702
status-firefox52: disabled → fixed
status-firefox52: fixed → verified

Comment 72

8 months ago
Fonts are still blurry with the gpu process.
Tab titles and tooltips still look much better with layers.gpu-process.dev.enabled = false.
Keywords: nightly-community
QA Contact: Virtual
You need to log in before you can comment on or make changes to this bug.