Last Comment Bug 564444 - [DWrite] rendering of text with @font-face includes dots in lower-right corner of each glyph
: [DWrite] rendering of text with @font-face includes dots in lower-right corne...
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Layout: Text (show other bugs)
: Trunk
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Jonathan Kew (:jfkthame)
:
Mentors:
http://mozillalabs.com/jetpack/2010/0...
: 617826 (view as bug list)
Depends on: 615905 692744
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-07 09:32 PDT by Ted Mielczarek [:ted.mielczarek]
Modified: 2011-10-13 22:18 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
bad rendering (185.74 KB, image/png)
2010-05-07 09:33 PDT, Ted Mielczarek [:ted.mielczarek]
no flags Details
selection screenshot (295.35 KB, image/png)
2010-12-09 03:58 PST, voracity
no flags Details

Description Ted Mielczarek [:ted.mielczarek] 2010-05-07 09:32:08 PDT
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 Ted Mielczarek [:ted.mielczarek] 2010-05-07 09:33:21 PDT
Created attachment 444108 [details]
bad rendering

Somehow failed to attach this.
Comment 2 Jonathan Kew (:jfkthame) 2010-05-07 10:45:13 PDT
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 3 Jonathan Kew (:jfkthame) 2010-12-09 02:22:58 PST
*** Bug 617826 has been marked as a duplicate of this bug. ***
Comment 4 Jonathan Kew (:jfkthame) 2010-12-09 02:24:48 PST
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 2010-12-09 03:58:44 PST
Created attachment 496477 [details]
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 Ted Mielczarek [:ted.mielczarek] 2010-12-09 05:30:31 PST
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) 2010-12-09 06:06:15 PST
To clarify, do you see this problem with D2D(+DWrite) rendering, or does it occur only with GDI+DWrite?
Comment 8 Ted Mielczarek [:ted.mielczarek] 2010-12-09 06:23:32 PST
I have DWrite enabled, but not D2D.
Comment 9 voracity 2010-12-09 06:29:13 PST
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) (Exited; email my personal email if necessary) 2010-12-11 23:01:15 PST
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) (Exited; email my personal email if necessary) 2010-12-11 23:13:20 PST
I think this should block, but we can fix it by just disabling D2D for all but D3D10.
Comment 12 Jonathan Kew (:jfkthame) 2010-12-12 07:01:28 PST
(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) (Exited; email my personal email if necessary) 2010-12-12 17:58:07 PST
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) 2010-12-12 22:06:18 PST
(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 2010-12-13 04:42:20 PST
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) 2010-12-13 14:20:28 PST
This is caused by using GDI + DirectWrite, which isn't a supported combination, so it doesn't block.
Comment 17 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2010-12-13 14:24:53 PST
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) 2011-10-10 07:07:13 PDT
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) 2011-10-13 07:42:04 PDT
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 Ted Mielczarek [:ted.mielczarek] 2011-10-13 08:02:00 PDT
I don't have the computer that I originally filed this with, so that's fine with me.
Comment 21 j.j. 2011-10-13 13:07:25 PDT
*** Bug 690331 has been marked as a duplicate of this bug. ***
Comment 22 voracity 2011-10-13 17:03:54 PDT
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) 2011-10-13 22:18:06 PDT
(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.

Note You need to log in before you can comment on or make changes to this bug.