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
Weird. To clarify, it looks like the dot is only occurring at the lower right corner of each glyph *run*, not each individual glyph.
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.
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).
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).
blocking2.0: --- → ?
To clarify, do you see this problem with D2D(+DWrite) rendering, or does it occur only with GDI+DWrite?
I have DWrite enabled, but not D2D.
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).
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)
I think this should block, but we can fix it by just disabling D2D for all but D3D10.
blocking2.0: ? → final+
(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.
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.
(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.
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.
This is caused by using GDI + DirectWrite, which isn't a supported combination, so it doesn't block.
blocking2.0: final+ → -
If it only happens for downloaded fonts, after we recover from a driver crash, I agree this doesn't need to block.
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.
8 years ago
Depends on: 692744
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.
Assignee: nobody → jfkthame
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
I don't have the computer that I originally filed this with, so that's fine with me.
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.
(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.
You need to log in before you can comment on or make changes to this bug.