1730772 - GDocs has very poor glyph rendering with D2D canvas

Status: VERIFIED FIXED

(Core :: Graphics: Canvas2D, defect, P1)

Description

[Bas Schouten (:bas.schouten)]

Attachment: image.png

Google Docs appears to have started pushing canvas backed google docs by default for some documents. See an example here (Most Mozilla accounts seem to be getting canvas backed GDocs on this doc):

https://docs.google.com/document/d/1-DkkjJ069KD8mJOcl5MW6jJkfbRV_kNbx1aTb6mngcY/edit#

We're seeing very poor Glyph rendering (kerning/hinting and AA/gamma). See attached image. As far as we can tell this is happening everywhere where we're using Windows an D2D canvas, and this may be somewhat worse when using DPI scaling.

Comment 1

[Bas Schouten (:bas.schouten)]

I was thinking about this a bit, I wonder if the poor kerning is due to DPI scaling. I'm not sure how DPI scaling works with canvases. But if the text was hinted for a smaller size and then drawn at a higher resolution, that would look quite bad. Indeed, if I set my DPI scaling to 100% and make the font size 1.5 times bigger, the glyphs look a lot better placed. (Although the poor AA remains, this seems to be improves significantly by disabling D2D)

Comment 2

[Kelsey Gilbert [:jgilbert]]

Yeah, the Chrome behavior looks too smooth to me. I wonder if the canvases are actually the same size, even?

Comment 3

[Bas Schouten (:bas.schouten)]

(In reply to Jeff Gilbert [:jgilbert] from comment #2)

Yeah, the Chrome behavior looks too smooth to me. I wonder if the canvases are actually the same size, even?

According to DevTools they are :-)

Comment 4

[Bas Schouten (:bas.schouten)]

In both cases the Canvas appears to be sized at 1224x1584 on my machine, but the style displays it as 816x1056. I.e. the Canvas is sized by the page with DPI scaling in mind, to match its pixels with the monitor. When I disable DPI scaling the canvas is 816x1056 just like the display size.

Comment 5

[Jim Mathies [:jimm]]

Some related notes -

1. we can ask google to opt people into their testing, so you can use a extra url param to control which implementation you get. Let me know if you would like to be added to this. The added param is mode=canvas or mode=html

2. I noticed a while back that gdocs would switch to the canvas implementation based on content that was in the doc. (pasted content tended to trigger this.) I have about 50% of my 1x1 notes that have converted over at some point.

3. We tested the canvas implementation a month or so ago and found it lacked subpixel aa. We experienced the same in Chrome. Generally the quality of the two browsers was about the same.

Comparing the two browsers today, it does seem as though the implementation in Firefox regressed in terms of quality from what I remember seeing a couple months ago. I'll do some testing in older builds to see if something might have regressed on our end.

Comment 6

[Jim Mathies [:jimm]]

Attachment: samples.jpg

fx -html
fx - canvas
ch - html
ch - canvas

Comment 7

[Benny Martinson]

Here's a minimal repro case: https://jsfiddle.net/x6r7fkzd/. It turns out this issue is caused by 11pt text scaled by 1.25. We can see the issue both on the canvas and in the DOM.

Comment 8

[Bas Schouten (:bas.schouten)]

I looked into this and found something with the help of jfkthame.. setting gfx.font_rendering.cleartype_params.force_gdi_classic_max_size to 0 fixes this issue.

Comment 9

[Bas Schouten (:bas.schouten)]

(In reply to Benny Martinson from comment #7)

Here's a minimal repro case: https://jsfiddle.net/x6r7fkzd/. It turns out this issue is caused by 11pt text scaled by 1.25. We can see the issue both on the canvas and in the DOM.

This actually looks fine for me in the regular version but looks awful on the Canvas.

Comment 10

[Bas Schouten (:bas.schouten)]

Attachment: image.png

Comment 11

[Benny Martinson]

It looks like you're on a display with devicePixelRatio > 1, so the html and canvas are rendered differently. If you test this on a display where devicePixelRatio=1 you should see the same thing in both cases, but please let me know if you don't.

Comment 12

[Bas Schouten (:bas.schouten)]

Attachment: image.png

Still a little difference, the kerning issue applies to both now. However the poor anti-aliasing issue is still primarily affecting Canvas. I'm guessing this is because the GDI classic mode does better on the opaque background of the DOM than the transparent background of the canvas.

Comment 13

[Bas Schouten (:bas.schouten)]

So if I Ctrl+Zoom, at devicePixelRation == 1, the canvas text will continue to use GDI classic but the DOM text will not, this of course makes perfect sense since the canvas won't actually change in pixel size. I think the right thing at least for Canvas here is never to use GDI classic rendering, there's probably something we want to do here for content as well, but I think that isn't quite as urgent.

Comment 14

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1730772: Do not use GDI classic rendering on transparent DrawTargets (mainly Canvas). r=jfkthame,jrmuizel

Comment 15

[Bas Schouten (:bas.schouten)]

Attachment: image.png

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84d7adc6d3ef
Do not use GDI classic rendering on transparent DrawTargets (mainly Canvas). r=jfkthame,jrmuizel

Comment 17

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/84d7adc6d3ef

Comment 18

[Cristian Tuns]

Backed out for causing Bug 1731207 for text rendering issue.

• Backout link

Comment 19

[Bas Schouten (:bas.schouten)]

Attachment: Bug 1730772: Do not use GDI classic rendering when rendering Canvas. r=jfkthame,jrmuizel

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3ba451ee28d1
Do not use GDI classic rendering when rendering Canvas. r=jfkthame,jrmuizel

Comment 21

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/3ba451ee28d1

Comment 22

[Bas Schouten (:bas.schouten)]

Comment on attachment 9241816 [details]
Bug 1730772: Do not use GDI classic rendering when rendering Canvas. r=jfkthame,jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Very poor rendering of glyphs in Google Docs with Canvas. Which is in the process of being rolled out to a larger population (currently @20%).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch will only affect canvas and change glyph rendering there. There should be very limited risk of it affecting any other codepaths.
• String changes made/needed: None

Comment 23

[Bas Schouten (:bas.schouten)]

(In reply to Bas Schouten (:bas.schouten) from comment #22)

Comment on attachment 9241816 [details]
Bug 1730772: Do not use GDI classic rendering when rendering Canvas. r=jfkthame,jrmuizel

Beta/Release Uplift Approval Request

• User impact if declined: Very poor rendering of glyphs in Google Docs with Canvas. Which is in the process of being rolled out to a larger population (currently @20%).
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch will only affect canvas and change glyph rendering there. There should be very limited risk of it affecting any other codepaths.
• String changes made/needed: None

I should note that, as with every change to text rendering. Some users may not like this change. Having said that that is almost certainly going to be a minority and this change makes our behavior much more similar to the competition's.

Comment 24

[Pascal Chevrel:pascalc (PTO until April 26)]

Comment on attachment 9241816 [details]
Bug 1730772: Do not use GDI classic rendering when rendering Canvas. r=jfkthame,jrmuizel

93 RC is already built and ships next week. We have a short release cycle, I think this can probably wait 94 or a 93 dot release.

Comment 25

[Alin Ilea, Desktop QA]

Reproduced the issue in Release 92, using Win10.
Verified - Fixed in Beta 94.0b2 (build id: 20211005185813) and latest Nightly 95.0a1 (build id: 20211007091917).