DirectWrite plans

[Mike Reed]

If you don't care about using DirectWrite in Skia or Chrome, you can stop reading.

We are hoping to use DirectWrite as the font rasterizing backend on Windows in the future. To our (and IE's) eyes, it gives prettier results than GDI, and it at least allows us to start using subpixel positioning in the future (FreeType and MacOS let us do that today, but we are not utilizing it yet).

We already have a running SkFontHost backend using DirectWrite in Skia for testing, and are now looking at what it will take to integrate that into Chrome-Win. There are basically two major hurdles:

1. Call Skia rather than GDI when finding, creating, and measuring fonts in Chrome.

2. Provide access to the raw font-data in the sandboxed process where webkit is running (we have a similar issue with GDI today).

#1 is required, since the DW shapes can differ from the GDI shapes, and therefore we need to measure and draw from the same engine. Today we measure directly via GDI, but draw via Skia. This works, as Skia is generating its glyphs from GDI behind the scenes. Switching the Chrome call-sites to make Skia calls rather than GDI can be done now, w/o any DW specific changes, as it should be a no-op in terms of fidelity. It should also have the side-effect of allowing us to share more code between the ports, since we call Skia to measure on the Linux port already (and will make similar changes to the Mac port to call Skia).

#2 requires #1 to be in place. We may be able to leverage off of the existing cache that we use for GDI fonts, but more investigation is needed.

Ben Wagner is leading the DW port effort, so if you have specific questions or suggestion, you can contact him directly if you wish.

thanks,

[Peter Kasting]

On Thu, Jan 12, 2012 at 2:18 PM, Mike Reed <re...@google.com> wrote:

We are hoping to use DirectWrite as the font rasterizing backend on Windows in the future. To our (and IE's) eyes,

And Firefox'!

Thanks for working on this.  Over time I've had more and more users asking for this, so I'm really pleased that we're doing it.

PK

[sunwangme]

how about xp?

[George Yakovlev]

Unfortunately, you need to provide both GDI and DirectWrite paths; fortunately :) the DirectWrite library could be delay-loaded, so app starts on XP.

(I do not know how it is actually implemented in Chrome, I just state that it is *possible*)

G.

how about xp?

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev

[Brian Stell]

Would I be correct in assuming that the API has sub-pixel positioning input/outputs and the code "under the hood" converts it to full pixel as necessary?

On Thu, Jan 12, 2012 at 2:18 PM, Mike Reed <re...@google.com> wrote:

[Hironori Bono (坊野 博典)]

Greetings Mike,

Many thanks for your hard work to replace GDI with DirectWrite.
I'm interested in the ETA when Chrome switches its font-rendering code
to DirectWrite. To describe the background of my question, we have
been working for fixing some font-rendering issues happening on a
sandboxed renderer <http://crbug.com/80235>. To investigate this
issue, Chrome cannot render characters because it cannot preload all
fonts used by the pager to the GDI cache. Even though we have been
working hard to fix this issue, I'm getting concerned that our work
may becomes in vain once when Chrome switches its font-rendering code
to DirectWrite. (Whichever Chrome switches its font-rendering code
from GDI to DirectWrite, we need to fix this issue for XP.) Would it
be possible to give me when you switches the font-rendering code of
Chrome to DirectWrite?

Regards,

Hironori Bono
E-mail: hb...@chromium.org

[Brad Dunzer]

This is great news. The web font community is going to be very
pleased.

Brad

> > Chromium Developers mailing list: chromium-...@chromium.org

[Claudio Holanda Jr.]

Well, I would love to know how much have been done implementing it. Btw, probably Windows 8 will enable DirectWrite by default. If not, they will at least let the user enable it via Control Panel, I supose...

[Mehrdad Niknami]

A lot of people have mentioned that DirectWrite looks better than GDI, but I'm having a hard time seeing this on Windows 8 (or Windows 7 for that matter).

Chrome renders (I presume with GDI):

whereas IE 10 renders:

Maybe it's just me, but IE's looks a lot blurrier to me (and it hurts my eyes).

Are my settings wrong, or is it just me who thinks DirectWrite is blurrier?

--
Chromium Developers mailing list: chromi...@chromium.org

[James Robinson]

On Mon, Jun 18, 2012 at 6:50 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:

A lot of people have mentioned that DirectWrite looks better than GDI, but I'm having a hard time seeing this on Windows 8 (or Windows 7 for that matter).

Chrome renders (I presume with GDI):

whereas IE 10 renders:

Maybe it's just me, but IE's looks a lot blurrier to me (and it hurts my eyes).

Are my settings wrong, or is it just me who thinks DirectWrite is blurrier?

Your IE10 screenshot appears to have grayscale text (no subpixel AA at all), so it's not quite a fair comparison to subpixel AA'd GDI-produced text.  My first inclination would be to believe that this is a bug either with your settings or IE10, not with DirectWrite itself.

- James

[Mehrdad Niknami]

Your IE10 screenshot appears to have grayscale text (no subpixel AA at all), so it's not quite a fair comparison to subpixel AA'd GDI-produced text.  My first inclination would be to believe that this is a bug either with your settings or IE10, not with DirectWrite itself.

This is a fresh install, so if there's a bug, I'd guess it must be in IE?

Sorry if it wasn't a fair comparison -- but I only compared it with IE because the email below said:

To our (and IE's) eyes, it gives prettier results than GDI

Thanks for the reply!

[Peter Kasting]

On Mon, Jun 18, 2012 at 6:50 PM, Mehrdad Niknami <mnik...@chromium.org> wrote:

Are my settings wrong, or is it just me who thinks DirectWrite is blurrier?

This is a technical implementation list, so I suggest another forum for debating whether DirectWrite is in general a preferable font rasterizer etc.

PK

[Duy Dang]

I hope DirectWrite will be included in Chrome soon.

[Loque Nahak]

Hello Mike,

9 months later, are there any relevant news? Will Chrome/Windows ever switch to DirectWrite?

I hope one day I will be able to correctly render/display Google-web-fonts on a Google-browser.

[Claudio Holanda Jr.]

I wonder why Microsoft didn't added  ative DirectWrite engine to default system's fonts, I mean, Windows 8 was a new opportunity to overwrite the shitty and non-antialiasing windows default font engine.

Anyway, now about Chrome, I think that at least for Windows 8, the DirectWrite should be used by default in the browser, the fonts look gorgeous rendered with this anti-aliasing, maybe even better than on OS X.

[Loque Nahak]

Well, Windows 8 has a long way to go, in my opinion, before seeing is as the "default" windows OS. Meanwhile Win7 users will keep experiencing a horrible font rendering on Chrome :-| and that really su*ks for web developers.

[Jake]

The DirectWrite font backend is in the skia tree now, so I suspect it won't be long until it's being used in chrome.

--

[Stuart Morgan]

Once again, this is a development list:
- If you want updates on the progress of a change, find the relevant
bug in crbug.com and star it.
- If you want to have general discussions about what you think should
happen, try chromium-discuss.
Either way, please don't spam everyone on chromium-dev.

-Stuart

2012/10/26 Loque Nahak <lo...@loquenahak.net>:

[Loque Nahak]

> Either way, please don't spam everyone on chromium-dev. 

Sorry, did not mean to do so. Opting out now, thank you for your time.