Uneven font kerning when using directwrite for font rendering

NEW
Unassigned

Status

()

Core
Graphics: Text
3 years ago
a year ago

People

(Reporter: Greg Edwards, Unassigned)

Tracking

({regression})

33 Branch
x86_64
Windows 8.1
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [gfx-noted])

Attachments

(5 attachments)

(Reporter)

Description

3 years ago
Created attachment 8514560 [details]
badkerning.png

User Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141027150301

Steps to reproduce:

Open about:config and make sure gfx.font_rendering.directwrite.enabled is set to true.
Restart Firefox if necessary.
Type "lllllllllllllllllllllllllll" into the address bar.


Actual results:

The spacing between characters ("kerning") varies wildly.


Expected results:

The kerning should be (more or less) even, thanks to subpixel positioning, as it was on Firefox 32.
(Reporter)

Updated

3 years ago
Component: Untriaged → Graphics: Text
Product: Firefox → Core
(Reporter)

Updated

3 years ago
Keywords: regression

Comment 1

3 years ago
Created attachment 8515061 [details]
ff33-win7.png

I'm not able to reproduce it with FF33 on Win 7.
(Reporter)

Comment 2

3 years ago
My gut tells me that GDI rendering is being used in that screenshot. Can I please get a screenshot of ordinary text to confirm?
Can you provide your about:support graphics output?
Flags: needinfo?(edwardsgreg)
Keywords: regressionwindow-wanted
Summary: Uneven font kerning → Uneven font kerning when using directwrite for font rendering
(Reporter)

Comment 4

3 years ago
Adapter Description	Parallels Display Adapter (WDDM)
Adapter Drivers	prl_umdd prl_umdd10
Adapter RAM	Unknown
ClearType Parameters	Gamma: 2200 Pixel Structure: R ClearType Level: 0 Enhanced Contrast: 100
Device ID	0x4005
Direct2D Enabled	Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled	true (6.3.9600.17111)
Driver Date	10-16-2014
Driver Version	10.1.28600.0
GPU #2 Active	false
GPU Accelerated Windows	0/1 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues.
Vendor ID	0x1ab8
WebGL Renderer	Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
Flags: needinfo?(edwardsgreg)
Seems like this bug slipped through the cracks. Greg, are you still able to reproduce this with the latest Firefox release?
Flags: needinfo?(edwardsgreg)
(Reporter)

Comment 6

2 years ago
The current release is preventing me from using DWrite entirely, which seems to render this issue moot. If I can find a setup which allows DWrite, I'll let you know.
Flags: needinfo?(edwardsgreg)
(In reply to Greg Edwards from comment #6)
> The current release is preventing me from using DWrite entirely, which seems
> to render this issue moot. If I can find a setup which allows DWrite, I'll
> let you know.

See bug 1207258. You should be able to force-enable dwrite again in the latest Nightly build, though IIRC the name of the pref has changed.
Created attachment 8688667 [details]
fx44 screenshot with acceleration disabled & dwrite forced on

Using Fx44 (the current Developer Edition) on Win10, I force-disabled layers acceleration (layers.acceleration.disabled: true) and while the fonts are noticeably less smooth, I wasn't able to reproduce the issue with or without directwrite forced on (gfx.font_rendering.directwrite.enabled: true/false).

Greg, can you try a current Nightly45 or DevEdition44 build with dwrite forced on and see how things look for you?
Flags: needinfo?(edwardsgreg)
(Reporter)

Comment 9

2 years ago
Created attachment 8688707 [details]
fx44badkerning.png

Yup, still happens in Aurora 44. In this screenshot, the URL bar shows the bad kerning, but the blue suggestion box below it is correct. I think it's triggered when attempting to render to a surface with an alpha channel.
Flags: needinfo?(edwardsgreg)
(Reporter)

Comment 10

2 years ago
Also Ryan, I should add, it looks like DWrite is still turned off in your screenshot. All the characters are aligned to the pixel grid. If I'm wrong and your font is somehow aligning to the pixel grid anyway, I think that would hide the issue.
That's disappointing :(

Greg, would you be willing to try narrowing down a regression range so we can better pinpoint what caused this? Since we already know that it regressed between Fx32 and Fx33, it shouldn't take very long. We have a tool called mozregression that automates the whole process of downloading and running the different builds. http://mozilla.github.io/mozregression/

A command like |mozregression --good-release 32 --bad-release 33| should be all that's needed to get started. Thanks!
(Reporter)

Comment 12

2 years ago
26:09.59 LOG: MainThread Bisector INFO Narrowed nightly regression window from [2014-05-19, 2014-05-21] (2 days) to [2014-05-20, 2014-05-21] (1 days) (~0 steps left)
26:09.59 LOG: MainThread main INFO Got as far as we can go bisecting nightlies...
26:09.59 LOG: MainThread Bisector INFO Last good revision: cb9f34f73ebe (2014-05-20)
26:09.59 LOG: MainThread Bisector INFO First bad revision: 9d8d16695f6a (2014-05-21)
26:09.59 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cb9f34f73ebe&tochange=9d8d16695f6a
26:09.59 LOG: MainThread Bisector INFO ... attempting to bisect inbound builds (starting from 4 days prior, to make sure no inbound revision is missed)
26:11.22 LOG: MainThread main INFO Getting inbound builds between 58c5a3427997 and 9d8d16695f6a
26:59.36 LOG: MainThread main INFO There are no build artifacts on inbound for these changesets (they are probably too old).
You rock, thanks for doing that!

The obvious-looking change in that range is Windows OMTC being enabled. Can you see if the layers.offmainthreadcomposition.enabled pref has any effect on what you're seeing? If that doesn't help, we can look for other possibilities in the range.
(Reporter)

Comment 14

2 years ago
Disabling offmainthreadcomposition via pref had no effect.
Created attachment 8689667 [details]
fx40-accel_off-dwrite_on-omtc_on.png

What theme are you using, out of curiosity? I set up a Windows 7 VM and have ended up with a very similar about:support section to what you're showing, but even on Fx40 w/ DWrite enabled, I'm seeing uniformity :(

Graphics
--------
Adapter Description: VMware SVGA 3D
Adapter Drivers: vm3dum
Adapter RAM: 1024
Asynchronous Pan/Zoom: none
Device ID: 0x0405
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: true (6.1.7601.17514)
Driver Date: 7-29-2014
Driver Version: 8.14.1.51
GPU #2 Active: false
GPU Accelerated Windows: 0/1 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues.
Subsys ID: 040515ad
Supports Hardware H264 Decoding: false
Vendor ID: 0x15ad
WebGL Renderer: Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0
(Reporter)

Comment 16

2 years ago
For starters, it's Windows 8.1, and I know for a fact that some font rendering changes were made in Windows 8. The visual style and Firefox theme are both default.

The ls in your screenshot still aren't as blurry as I'd expect them to be if DWrite was working. Can you make a screenshot with letters other than l?

I can also trigger the bug in HTML documents. I'll get you a testcase shortly.
http://imgur.com/TAIwWul
Another fun fact, AFAICT, gfx.font_rendering.directwrite.force-enabled doesn't actually do anything on Fx44+ either. Even shows as disabled still in about:support.
(Reporter)

Comment 19

2 years ago
I turned off DPI scaling and now I see exactly what you see. The bug still exists elsewhere but the address bar can't be used to replicate it.

See if you can replicate it via the Start Page search, like so:
http://puu.sh/lrumI/e8afa54ffc.png
Good news, I can reproduce in my Win7 VM using the New Tab Page search bar and the gfx.font_rendering.directwrite.force-enabled & layers.acceleration.force-enabled prefs set to true :)
Even better news, I was able to bisect this down locally :)

Regression range: https://hg.mozilla.org/integration/mozilla-inbound/rev/46d9ffb97fe3

So it was the OMTC enabling indeed. So, the next question of course is why disabling OMTC now doesn't make the regression go away. That I haven't managed to track down yet. I've confirmed that disabling OMTC in Fx33 already doesn't make this regression go away (though it definitely does in the builds immediately after it was turned on).
Blocks: 899785
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regressionwindow-wanted
Range where the issue doesn't occur whether OMTC enabled or not (even with layers.acceleration.force-enabled set to true): https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=869971ad9fd6&tochange=a74600665875 (first seen in the 2014-07-17 nightly build)

I suspect that bug 1036785 is what made the behavior change, but don't have the time to bisect the range tonight to confirm that.
Does this still reproduce?
Flags: needinfo?(ryanvm)
Whiteboard: [gfx-noted]
(Reporter)

Comment 24

a year ago
Yes. The trigger seems to be using DWrite without D2D when rendering to a buffer with an alpha channel.
Note that the start page search bar no longer shows the issue since it isn't rendering with an alpha channel anymore, but the address bar still works.
Flags: needinfo?(ryanvm)
You need to log in before you can comment on or make changes to this bug.