Closed Bug 675383 Opened 13 years ago Closed 13 years ago

DWrite font using GDI rendering mode has erratic spacing when a transform (e.g. synthetic italics) is in effect

Categories

(Core :: Graphics, defect)

All
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla9
Tracking Status
firefox7 + wontfix
firefox8 + fixed

People

(Reporter: b1437400, Assigned: jfkthame)

References

Details

(Keywords: regression, testcase)

Attachments

(6 files, 2 obsolete files)

Attached image Ugly italic font (obsolete) —
1. Visit this page: http://forums.miranda-im.org/showthread.php?713-ICQ-Protocol-Discussion/page225
2. Focus your attention on the italic text in quoted messages.
3. Scroll the page up/down
4. Go to 2.

This is what I get (watch the attached screenshot).

If I select and de-select this text - it gets redrawn properly, until I scroll up/down again.

Latest Nightly.

Adapter Description NVIDIA GeForce GTX 560
Vendor ID 10de
Device ID 1201
Adapter RAM 1024
Adapter Drivers nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um
Driver Version 8.17.12.7533
Driver Date 5-20-2011
Direct2D Enabled true
DirectWrite Enabled true (6.1.7601.17563)
ClearType Parameters ClearType parameters not found
WebGL RendererGoogle Inc. -- ANGLE -- OpenGL ES 2.0 (ANGLE 0.0.0.686)
GPU Accelerated Windows1/1 Direct3D 10
Attached image Comparison (obsolete) —
The comparison.
At the bottom is the same message, but after selecting and de-selecting the text.
Attachment #549524 - Attachment is obsolete: true
Keywords: testcase-wanted
Product: Firefox → Core
QA Contact: general → general
Component: General → Layout: Text
QA Contact: general → layout.fonts-and-text
Attached file reduced html
Attached image screen shot
Letter spacing is drawn at random.
And when I select text, the latter spacing is slightly changed.
Regression window(cached m-c hourly:
Works:
http://hg.mozilla.org/mozilla-central/rev/09aa6c7e5867
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110602 Firefox/7.0a1 ID:20110602165615
Fails:
http://hg.mozilla.org/mozilla-central/rev/8a133638f5b6
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110602 Firefox/7.0a1 ID:20110602225429
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=09aa6c7e5867&tochange=8a133638f5b6

Suspected bug:
Bug 661471 - Create preference(s) to allow specific font families to be forced to use GDI Classic rendering
Blocks: 661471
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Component: Layout: Text → Graphics
QA Contact: layout.fonts-and-text → thebes
Summary: Italic font is not drawn properly → Italic font is not redrawn properly when scrolling
Attachment #549526 - Attachment is obsolete: true
Whiteboard: [regression from 661471]
In additio to the above,
When change browser width, the letter is dancing.
This appears to happen only when
(a) the font is being rendered via D2D/DWrite using GDI Classic mode, and
(b) there is no real italic/oblique face, so synthetic oblique is being used.
This testcase makes the erratic spacing really obvious in Tahoma with font-style:italic.

It also demonstrates that the same problem can occur in non-italic text when other transforms are used; the root of the problem lies in the presence of a transform. Use of italic style with a font that doesn't have a true italic or oblique face just happens to be the likeliest way to trigger the use of a transform on the text.

Note that scrolling the testcase vertically, even by just a single pixel, and then reloading will cause the erratic spacing in the italicized Tahoma to shift around. It also shifts during drag-selecting through the text, as different sub-runs get repainted.
Assignee: nobody → jfkthame
Hardware: x86_64 → All
Summary: Italic font is not redrawn properly when scrolling → DWrite font using GDI rendering mode has erratic spacing when a transform (e.g. synthetic italics) is in effect
Version: 8 Branch → Trunk
The problem arises when glyph positions fall exactly on half pixels, and then end up rounding erratically to whole-pixel positions after the transform-and-inverse-transform calculations introduce small floating-point errors. So the idea here is to add a small offset - tiny enough to be insignificant in comparison to appUnit coordinates - so that we nudge the values just enough that they're likely to round consistently even after the transforms.

I suppose it's possible that under "extreme" transformations, the error introduced by the matrix operations might still be enough to cause problems, but I think this should resolve the problem for any reasonable use-case.
Attachment #556810 - Flags: review?(bas.schouten)
Comment on attachment 556810 [details] [diff] [review]
patch, v1 - add a tiny delta to glyph x-coordinates to ensure consistent rounding to whole pixels

Review of attachment 556810 [details] [diff] [review]:
-----------------------------------------------------------------

Seems like a decent pragmatic solution to me!
Attachment #556810 - Flags: review?(bas.schouten) → review+
http://hg.mozilla.org/integration/mozilla-inbound/rev/f1dbc0a63703
Whiteboard: [regression from 661471] → [inbound]
http://hg.mozilla.org/mozilla-central/rev/f1dbc0a63703
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla9
Setting resolution to Verified Fixed on Mozilla/5.0 (Windows NT 6.1; rv:9.0a1) Gecko/20110908 Firefox/9.0a1

I have used the simplified additional test case in order to verify this and now it works fine.

I have one question: why is this bug flagged tracking-firefox7 if it's target milestone is firefox 9?
Thanks
Status: RESOLVED → VERIFIED
We flagged it was caused by a fix that made it in Firefox 7 and would likely appear to be a regression to users.
Comment on attachment 556810 [details] [diff] [review]
patch, v1 - add a tiny delta to glyph x-coordinates to ensure consistent rounding to whole pixels

Nominating for Aurora and Beta, as the regression will be visible to Windows users in common styles such as Tahoma italic, and the patch is extremely low risk - it just perturbs glyph positions by a tiny amount when drawing, in order to give predictable rounding behavior for positions that would otherwise be unstable under the effects of floating-point precision limits. There is no wider effect on layout, so I don't think there is any risk of breakage elsewhere due to this fix.
Attachment #556810 - Flags: approval-mozilla-beta?
Attachment #556810 - Flags: approval-mozilla-aurora?
Whiteboard: [inbound]
We haven't seen any user complaints and the problem seems to be superficial in an edge-case scenario. We're denying for beta as we are late in the game.
Attachment #556810 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Comment on attachment 556810 [details] [diff] [review]
patch, v1 - add a tiny delta to glyph x-coordinates to ensure consistent rounding to whole pixels

Land it quickly, please!
Attachment #556810 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: