DWrite rendering in Firefox

John Hudson's picture

Some months back, it was announced here that Firefox 4.0 would use Microsoft's DirectWrite text rendering, meaning, among other things, that CFF OpenType fonts would be rendered using ClearType subpixel rendering, like TTFs, instead of the old, much lamented Windows PostScript rasteriser. When Firefox 4.0 arrived, I was surprised to find that DWrite rendering was not active by default, and that I had to manually set some config flags in order to activate it (not something I'd be comfortable recommending to the average browser user). This week I wrote to John Daggett at Mozilla, and asked him to comment on this and whether there is any change in Firefox 5.0. He graciously gave his permission for me to post his reply here, and to continue the discussion on this forum.

DirectWrite is on by default but only when hardware acceleration is enabled. There's a long list of whitelisted/blacklisted drivers that we maintain, mainly because of various driver bugs. MS has something similar but I imagine they can support a wider set of drivers because they know more about precisely where drivers have bugs. The latest numbers indicate that over half of Firefox users on Windows 7 run without acceleration enabled. That's based on a combination of underlying hardware and driver versions so those those running without acceleration will probably decrease over time as drivers get updated.

I'm pushing to have DirectWrite enabled *always* on machines that support it (i.e. whether hardware accelaration is enabled or not) but that's been hard to do because there's been a lot of pushback among users who are accustomed to existing GDI rendering. This is especially true for the core web fonts (Arial, Tahoma, Verdana) at 9-13ppem sizes. The default DirectWrite rasterization is relatively light and so there have been a fair number of complaints about fonts being "fuzzy". For now, we've created a list of fonts that default to GDI rendering at small sizes (<16ppem) with fonts like Arial, Tahoma, Verdana on it. I'm hoping we'll be able to sufficiently resolve this for those users to allow us to enable DirectWrite always in a future version.

One immediate thought that I have regarding this is that perhaps Mozilla could find a way to enable DWrite by default for CFF fonts? I don't think anyone is going to complain that this is worse than the old PS rasteriser rendering!

Richard Fink's picture

Thanks to you John (and John D) for shedding some light on this.

But if it's a hardware issue that's holding DWrite back in FF, I fail to see how the same hardware issues won't put the kabosh on CFF DWrite rendering, too.
The font flavor sounds irrelevant to the underlying problem.

Richard Fink's picture

Also, isn't it a big surprise that Microsoft seems to have the leg up on getting DWrite to work?
Hee, hee, hee, ha, ha, ha, ho, ho, ho.

Like Mel Brooks said in History Of The World Part I: "It's good ta be da king".

Si_Daniels's picture

Hardware issues aside, we issued an update to compensate for the rendering issue John identifies in the second paragraph... http://support.microsoft.com/kb/2545698

Cheers, Si

John Hudson's picture

Rich: But if it's a hardware issue that's holding DWrite back in FF, I fail to see how the same hardware issues won't put the kabosh on CFF DWrite rendering, too.

The second paragraph of John D's comments indicates that this is not fundamentally a hardware/driver issue, but a design decision, i.e. that it would be possible to enable DWrite by default ‘whether hardware acceleration is enabled or not’ (presuming an OS that supports DWrite). He further suggests that specific (TTF) fonts can be excluded by name, so what I'm wondering is if other (CFF) fonts could be included by flavour.

Also, isn't it a big surprise that Microsoft seems to have the leg up on getting DWrite to work?

MS invest in massive hardware testing and maintain a very extensive driver registry, so of course they have an advantage over companies that don't do the same level of hardware and driver testing.

Richard Fink's picture

@jh

Or who can't do the same level of hardware and driver testing.
It's Windows' world, pal, we're all just livin' in it.
So with envy and admiration I say again: it really is good ta be da king.

Obviously I might have missed an angle to what JD said. Will read harder.

@sii

Thanks for the link. Important to know.

rich

sergeym's picture

IE always uses D2D/DWrite. Only if there are known problems with graphics card or driver, IE9 will use D2D software rendering. This should produce the same (although slower) layout and rendering results as hardware accelerated mode, incuding ClearType with subpixel positioning.

Here is relevant post on IE team blog:

http://blogs.msdn.com/b/ie/archive/2011/04/01/getting-the-most-from-ie9-and-your-gpu.aspx

Besides rendering quality, compatibility of layout is also very important (e.g. same site laid out using pixel-aligned or subpixel glyph metrics). Having different layout results depending on user's hardware would be support nighmare, we went through this. It is not clear from John's response if this actually happens in FireFox.

Thanks,
Sergey

mike_duggan's picture

>>>One immediate thought that I have regarding this is that perhaps Mozilla could find a way to enable DWrite by default for CFF fonts? I don't think anyone is going to complain that this is worse than the old PS rasteriser rendering!

John, what results are you seeing for otf fonts in FF5? In some tests I am seeing DirectWrite ClearType rendering.

John Hudson's picture

Mike, I've not had an opportunity to test FF5 yet (too busy), but my understanding of John Daggett's comments is that you will see DWrite rendering of both CFF and TTF fonts in both FF4 and FF5 if hardware acceleration is enabled, but that some core TTF fonts are currently excluded due to negative user feedback on the rendering (perhaps fixed, according to Si's comment).

So what I take away from this is that what you will see in FF4 and 5 will depend on both the machine being used and which specific font is used.

My suggestion was that if, as John D suggests, it would be possible to support DWrite regardless of hardware acceleration, but there are concerns about rendering of some TTFs and hence the possibility of using DWrite for some fonts and GDI for others, it might be possible to first apply default DWrite rendering to CFF fonts, since they will more surely benefit relative to the old PS rendering.

sergeym's picture

I understand reasoning why decision about subpixel rendering can be based on font/size, but using hardware capabilities for this purpose is strange (you can use it for other puuposes, of course). Results on screen produced by DWrite should not depend on whether you use hardware or software rendering. And the other way around, DWrite provides ability to produce both subpixel ClearType or GDI-compatible rendering, independent from hardware mode. Would be interesting to hear what John D think.

Syndicate content Syndicate content