Closed Bug 1261699 Opened 9 years ago Closed 9 years ago

Canvas fillText character spacing issues with Skia canvas on Linux

Categories

(Core :: Graphics: Canvas2D, defect)

Product:
Core
Component:
Graphics: Canvas2D
Version:
45 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla48
Tracking Flags:
Tracking Status
firefox48 --- verified

People

(Reporter: i93.borg, Assigned: lsalzman)

References

Details

(Whiteboard: [gfx-noted])

Attachments

(6 files, 4 obsolete files)

1261699.html
994 bytes, text/html
Details
Capture d'écran 2016-04-03 à 23.31.10.png
21.41 KB, image/png
Details
ff_bz_1261699-04.png
105.07 KB, image/png
Details
Updated code sample
1.05 KB, text/html
Details
Contents of /etc/fonts/conf.d/
10.96 KB, application/x-compressed-tar
Details
preserve user fontconfig autohint settings in Cairo glyph rendering options
4.13 KB, patch
jfkthame
: review+
gw280
: feedback+
Details | Diff | Splinter Review
Attached image canvas_text_firefox.png (obsolete) —
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Build ID: 20160318175143 Steps to reproduce: Test code: ``` <!DOCTYPE html> <html lang="en"> <head> <title>Canvas Text Test</title> </head> <body> <canvas id="canvas" style="border: 1px solid #333"></canvas> <script> var canvas = document.getElementById('canvas'), ctx = canvas.getContext('2d'), xy = 100; canvas.width = xy; canvas.height = xy; ctx.clearRect(0, 0, xy, xy); ctx.textBaseline = 'top'; ctx.font = '10px sans-serif'; ctx.fillText('1234567890', 5, 5); ctx.font = '11px sans-serif'; ctx.fillText('1234567890', 5, 25); ctx.font = '12px sans-serif'; ctx.fillText('1234567890', 5, 45); ctx.font = '13px sans-serif'; ctx.fillText('1234567890', 5, 65); ctx.font = '14px sans-serif'; ctx.fillText('1234567890', 5, 85); </script> <body> </html> ``` Actual results: See attached screenshots. Firefox has issues with spacing - it varies and some characters overlap. Compare this to Chromium which does a better job. Expected results: Better looking text.
Attached image canvas_text_chromium.png (obsolete) —
Attached file 1261699.html —
WFM with FF45 on Win7
Component: Untriaged → Canvas: 2D
Product: Firefox → Core
jfkthame, can you comment to the bug?
Flags: needinfo?(jfkthame)
Whiteboard: [gfx-noted]
George, how do the Firefox & Chromium results compare if you specify a particular font (instead of the generic 'sans-serif', which looks like it is configured differently in the two browsers)? E.g. replace 'sans-serif' in your testcase a specific font family such as 'Liberation Sans' or 'Open Sans' or others that you may have installed. Does the problem you see in Firefox happen with *all* fonts, or is it related to one particular face?
Flags: needinfo?(jfkthame) → needinfo?(i93.borg)
Attached image ff_bz_1261699-02.png (obsolete) —
Looks my default is "Open Sans". Switching to "Liberation Sans" makes things better, but if you look at the spacing vs Chromium it is still not as consistent.
Flags: needinfo?(i93.borg)
Or maybe my default is actually "DejaVu Sans".
Attached image ff_bz_1261699-03.png (obsolete) —
FreeSans has better spacing, but one of the sizes cuts off the top of the text.
Attached image ff_bz_1261699-04.png —
I have added text string to my test and the results are not great...
Attachment #8737628 - Attachment is obsolete: true
Attachment #8737629 - Attachment is obsolete: true
Attachment #8742229 - Attachment is obsolete: true
Attachment #8742282 - Attachment is obsolete: true
Attached file Updated code sample —
Wow, that looks really bad! I don't see issues like this on my Linux system, though, so I wonder what's different. My current guess is that if you adjust system configuration settings like font hinting and antialiasing, that may affect the result; if so, it would be good to know what particular settings are "good" or "bad".
Looks like it's "gfx.canvas.azure.backends" - I set mine to "skia" a while back and forgot all about it. So looks like it's a choice between **** looking fonts or terrible canvas performance. :( Feel free to close this since it's not a supported configuration.
P.S. Thanks for your help though, sorry it was a bit of a wild goose chase!
And this is possibly a duplicate of bug 1208644? Although that case is not specifically focused on canvas, but it's also about text rendering.
Well, I don't think this should just be closed.... AIUI, the intention is to move to skia as the default (only?) backend, and if that's going to regress text rendering -- and your screenshots certainly look unacceptable! -- then there's a problem. In fact, it looks like the change has been made for Firefox 48 in bug 1244754, so I'm going to mark this as blocking that bug, and let the graphics/skia people take a look.
Blocks: 1244754
Flags: needinfo?(milan)
Flags: needinfo?(jmuizelaar)
Summary: Canvas fillText character spacing issues → Canvas fillText character spacing issues with Skia canvas on Linux
Flags: needinfo?(jmuizelaar) → needinfo?(lsalzman)
Is this fixed in nightly for you? We made some changes to subpixel text positioning around the time of the 45 release that may have regressed Skia/Cairo fonts, which we subsequently fixed more recently.
Flags: needinfo?(lsalzman) → needinfo?(i93.borg)
No, I still see the problem in nightly.
Flags: needinfo?(i93.borg)
(In reply to George from comment #17) > No, I still see the problem in nightly. I can't reproduce the issue here with nightly using Skia canvas. Can you paste the "Graphics" section of "about:support"?
Flags: needinfo?(i93.borg)
```` Features Compositing OpenGL Asynchronous Pan/Zoom wheel input enabled WebGL Renderer X.Org -- Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.1) Hardware H264 Decoding No GPU #1 Active Yes Description X.Org -- Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.1) Vendor ID X.Org Device ID Gallium 0.4 on AMD TURKS (DRM 2.43.0, LLVM 3.7.1) Driver Version 3.0 Mesa 11.1.2 Diagnostics AzureCanvasAccelerated 0 AzureCanvasBackend skia AzureContentBackend cairo AzureFallbackCanvasBackend none CairoUseXRender 0 ````
Flags: needinfo?(i93.borg)
Would you be willing to provide the contents of the files in /etc/fonts/conf.d for me? I would need to check the settings inside some of the files there. They may be symlinks so if you use tar, make sure to use the -h option to deference them. Also, what distribution/version of Linux?
Flags: needinfo?(i93.borg)
Flags: needinfo?(milan)
I am running Debian Sid, Linux 4.4.0 kernel.
Flags: needinfo?(i93.borg)
(In reply to George from comment #21) > Created attachment 8742526 [details] > Contents of /etc/fonts/conf.d/ > > I am running Debian Sid, Linux 4.4.0 kernel. I notice you have autohinting enabled, which I was sort of suspicious of being related to this. Still digging to find out what's going on, though...
So it looks like cairo-ft is checking the autohint setting in fontconfig when creating the font from it. However, this is not represented in Cairo's font options in the API. Thus, we need to check the fontconfig for autohinting, store it in the font, then pass it along when we go to create glyph rendering options. Skia needs this information passed along in the glyph rendering options so that it's font host can load the freetype font with the same load options Cairo is passing in cairo-ft. When they do not match, you end up with badly offset glyphs that can be improperly cropped as we observed here. Matching is good!
Assignee: nobody → lsalzman
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #8743627 - Flags: review?(jfkthame)
Comment on attachment 8743627 [details] [diff] [review] preserve user fontconfig autohint settings in Cairo glyph rendering options Review of attachment 8743627 [details] [diff] [review]: ----------------------------------------------------------------- Looks reasonable to me. I notice there's an explicit comment that "We don't want to force the use of the autohinter..." in the current code. AFAICS, that originates from gw280's patches in bug 736276, so perhaps we should ask him for a quick sanity-check just in case there was some other issue that we're overlooking here.
Attachment #8743627 - Flags: review?(jfkthame)
Attachment #8743627 - Flags: review+
Attachment #8743627 - Flags: feedback?(gwright)
Looking back at the original bug where that was added, I think we should be ok here.
Attachment #8743627 - Flags: feedback?(gwright) → feedback+
https://hg.mozilla.org/mozilla-central/rev/bcda23d0f3ca
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox48: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Flags: qe-verify+
Confirming the fix for this issue on Ubuntu 14.04 x64 using Firefox 48.0b2, build ID 20160620091522.
Status: RESOLVED → VERIFIED
status-firefox48: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: