564444 - [DWrite] rendering of text with @font-face includes dots in lower-right corner of each glyph

Status: RESOLVED FIXED

(Core :: Layout: Text and Fonts, defect)

Description

[(not currently active) Ted Mielczarek]

At the linked URL, which uses @font-face, I get a dot rendered in the lower right corner of each glyph. See attached screenshot. I have DWrite enabled.

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:1.9.3a5pre) Gecko/20100506 Minefield/3.7a5pre

Comment 1

[(not currently active) Ted Mielczarek]

Attachment: bad rendering

Somehow failed to attach this.

Comment 2

[Jonathan Kew [:jfkthame]]

Weird. To clarify, it looks like the dot is only occurring at the lower right corner of each glyph *run*, not each individual glyph.

Comment 4

[Jonathan Kew [:jfkthame]]

As pointed out in bug 617826, it seems the dot is really appearing at the lower *left* of each space rather than the lower *right* of the preceding glyph run.

Comment 5

[voracity]

Attachment: selection screenshot

I filed 617826. (I spent 20 minutes looking for an existing bug, but couldn't find one because I used the keyword 'DirectWrite'...)

Anyhoo, I updated my nVidia 7600 GS driver as requested, but I'm still having the same problem as shown in the screenshots in this bug and the dup.

One more thing to note is that if I select the space character, the dot does not appear in the selection. For completeness, I've attached a screenshot that shows this (the selection starts with the space character).

Comment 6

[(not currently active) Ted Mielczarek]

This is really annoying because the Mozilla Labs blog triggers it. It bothers me every time I read a blog post there (which winds up being fairly often).

Comment 7

[Jonathan Kew [:jfkthame]]

To clarify, do you see this problem with D2D(+DWrite) rendering, or does it occur only with GDI+DWrite?

Comment 8

[(not currently active) Ted Mielczarek]

I have DWrite enabled, but not D2D.

Comment 9

[voracity]

The 7600 GS doesn't support DirectX 10/Direct2D, so I can't test with it on.

On the (very) off chance it's related, there's also a current bug (bug 590568) where plugins overwrite chrome content with a white square. That's also affecting people using the 7600 GS (and related cards).

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think we should simply not support DirectWrite without D2D. I think on Windows we should only support:

BasicLayers+GDI
D3D9+GDI
D3D10+D2D(+DirectWrite)

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I think this should block, but we can fix it by just disabling D2D for all but D3D10.

Comment 12

[Jonathan Kew [:jfkthame]]

(In reply to comment #10)
> I think we should simply not support DirectWrite without D2D.

In that case we'll need to address the question of how we handle fonts if we switch from D2D+DW to all-GDI rendering on the fly. At that point, we need to replace the platform font list, along with all the cached font objects, etc.

In bug 606419 we fixed the crash by allowing DWrite to continue being used at that point, but if we want to disable that combination then we need to fix bug 615905.

Comment 13

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is that just to support dynamic pref changes? If so, I say, who cares? We don't have to support dynamic mode changes, and it's not worth writing much code to handle them.

Comment 14

[Jonathan Kew [:jfkthame]]

(In reply to comment #13)
> Is that just to support dynamic pref changes? If so, I say, who cares? We don't
> have to support dynamic mode changes, and it's not worth writing much code to
> handle them.

I'd definitely agree with that, and so I wasn't keen to do bug 615905. But it's not just for pref changes, unfortunately: the problem also arises when we encounter some kind of problem with D2D (driver crashes, device disappears, an update happens, etc - I don't really know what situations trigger it) and gfxWindowsPlatform::UpdateRenderMode() decides that D2D can't be used, so it switches to GDI rendering. This is what led to bug 606419, which we fixed for now by ensuring that we can continue to use the DW fonts after such a switch. But if we're not going to allow the GDI+DW combination, we need to reconsider what UpdateRenderMode() is doing and how to handle it.

Comment 15

[voracity]

Disabling DirectWrite when there's no Direct2D seems a bit harsh. The only glitch I've encountered in fairly intensive use over 5 something months of having DirectWrite+GDI is this dot. I consider rendering to be *significantly* better with DirectWrite on (which is why I've left DirectWrite on for 5 months despite knowing it causes the dot).

There are other issues with DirectWrite itself (due to fixes needed by MS), but that's regardless of whether using GDI or Direct2D.

Comment 16

[Joe Drew (not getting mail)]

This is caused by using GDI + DirectWrite, which isn't a supported combination, so it doesn't block.

Comment 17

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If it only happens for downloaded fonts, after we recover from a driver crash, I agree this doesn't need to block.

Comment 18

[Jonathan Kew [:jfkthame]]

This should be fixed by the patch in bug 692744, which relates to text-shadow (and is not limited to DWrite+GDI) but has the same root cause.

Comment 19

[Jonathan Kew [:jfkthame]]

I believe this had the same cause as bug 692744 (creating a 1x1 pixel surface for what should be an empty glyph image), and I can no longer reproduce it now that patch has landed - resolving as FIXED.

Comment 20

[(not currently active) Ted Mielczarek]

I don't have the computer that I originally filed this with, so that's fine with me.

Comment 22

[voracity]

I'm still getting the dots with [Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111013 Firefox/10.0a1] exactly as per the Dec 2010 screenshot I posted. (My hardware hasn't changed.)

Not that I consider this bug particularly important.

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to voracity from comment #22)
> I'm still getting the dots with [Mozilla/5.0 (Windows NT 6.1; WOW64;
> rv:10.0a1) Gecko/20111013 Firefox/10.0a1] exactly as per the Dec 2010
> screenshot I posted.

The first Nightly that includes the fix should be 20111014, as the patch landed in mozilla-central several hours after the 10/13 nightly builds.