Open
Bug 1091853
Opened 11 years ago
Updated 3 years ago
Uneven font kerning when using directwrite for font rendering
Categories
(Core :: Graphics: Text, defect, P3)
Tracking
()
NEW
People
(Reporter: edwardsgreg, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [gfx-noted])
Attachments
(5 files)
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•11 years ago
|
Component: Untriaged → Graphics: Text
Product: Firefox → Core
| Reporter | ||
Updated•11 years ago
|
Keywords: regression
| Reporter | ||
Comment 2•11 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?
Comment 3•11 years ago
|
||
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•11 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•10 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)
Comment 7•10 years ago
|
||
(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.
Comment 8•10 years ago
|
||
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•10 years ago
|
||
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•10 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.
Comment 11•10 years ago
|
||
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•10 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).
Comment 13•10 years ago
|
||
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•10 years ago
|
||
Disabling offmainthreadcomposition via pref had no effect.
Comment 15•10 years ago
|
||
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•10 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.
Comment 17•10 years ago
|
||
Comment 18•10 years ago
|
||
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•10 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
Comment 20•10 years ago
|
||
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 :)
Comment 21•10 years ago
|
||
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).
Comment 22•10 years ago
|
||
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.
| Reporter | ||
Comment 24•9 years 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.
Updated•9 years ago
|
Flags: needinfo?(ryanvm)
Updated•7 years ago
|
Priority: -- → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•