+dpranke since you commented on that thread too.

This is something eae@ have talked a bit about back and forth over the years (including using it on mac as well). bungeman@ and jshin@ have also weighed in ...

The latest thread I have on this goes roughly as follows:

eae@ wrote:
>dpranke@ wrote:
>> As for text, it's not clear to me either if there's a significant quality
>> difference between Core Text and DirectWrite and tip-of-tree FreeType these
>> days, but there are certainly some people that will notice and complain if
>> the text rendering in the browser looks slightly different from the rest of
>> the system UI.
>>
>> eae@ and drott@, cc'ed, probably can weigh in on whether such choices would
>> even really be on the table or not.
>
> The difference between Windows and Mac text rendering is pretty big
> and quite noticeable. Unless we can find a way to match the rendering
> (or get very close) with FreeType I think this is a non-starter sadly.

We've discussed mostly in the context of using freetype for text rendering in the layout tests (see bug 589330), where we don't care too much about either the absolute quality or the compatibility with the native engines; I think in that context we've concluded that it would be fine to switch 90%+ of the tests to FT as long as we could still exercise the native code paths.

Doing that would require us to be able to select the font engine choices at least at startup time. I believe the hooks we have make this relatively tractable, and that would also allow us to better evaluate whether FT was a viable alternative to DirectWrite or Core Text.

Yeah, it all comes down to whether we can emulate the system rendering closely enough.

I'd want to make a decision and bake it in if we're going to do it though. I don't want to have to debug sometimes-FreeType and sometimes-DirectWrite bugs, as we already have way too many switchable axes as it is.

I do really like the idea of a single font subsystem to maintain, including unified IPC surface and fuzzable code (even better that it would live in the renderer).

Well, yeah, I wasn't meaning to suggest that we'd be able to flip between the two at runtime in Chrome. And if we did flip to FT for Chrome unconditionally, we'd want that in content_shell for the layout tests.

My point was that it would be a way to implement/prototype something for better evaluation purposes, and even if we decided it wasn't viable for the product, the work would still be used (and valuable) for testing.

Oh, sorry, I was just giving my vote of support for the idea in principle.

If we can get the rendering to be close enough to windows native then I'm all for it. Whether that is practical or not is the million dollar question.

At this point, I personally haven't concluded how to prioritize this idea - there is plenty to work on in the are of Blink fonts, and not such a large number of people working on it. There is also the suggestion to unify Chrome UIs and Blink font rendering as one the larger scale projects.

I certainly see the security argument of reducing sandbox exceptions, and containing more components inside the renderer, but there is still things left we need from the system, for which I believe we will need sandbox exceptions. More below.

> https://crbug.com/409784#c80 for example is one example of DirectWrite's (I believe) baseline instability, at least in how Chrome uses it.

kulshin@ thankfully went through the crashes and in https://bugs.chromium.org/p/chromium/issues/detail?id=409784#c70 found that about half of these crashes come from about 100 users - indicating broken machines as one of the reasons. Also, we did have bugs with invalid font handles, and eae@ recent changes brought the Windows empty font handle crash rates down further, compare issue 561873.

I don't think we have data to say that DirectWrite has a lower baseline stability than our other subsystems. 


If we distance ourselves further from the system's font rendering on Windows and/or Mac, we still need access to system font blobs on those systems. If we do our own glyph rendering, we need to transfer the full 'glyf' table, most probably the full font blob from the system to the renderer memory. This means some form of IPC or file access rules exceptions for those files and most likely higher memory usage inside the renderer.

If we do glyph rendering inside DirectWrite and through CoreText, we can make use of font services of Windows and Mac that share the memory needed for handling glyf tables across applications.

On the gradient of things we can roll our own for, or use the OS'ses: For font fallback we still need to ask the system for a fallback font and rely on OS API to index the system's font coverage for us, unless we want to build our own 'cmap' table indexing service in the browser process.

jschuh@ expressed his support for a more unified IPC and I believe that there is room for improvement in this area without switching from DirectWrite to FreeType. With current work going on in Android, it looks like for font lookup and access on Android we will soon need IPC, too, instead of the current fonts.xml plus file based access approach. There is room here for us to in fact harmonize at least the font matching and font fallback parts of our font IPC. Some system specific sandboxing exceptions remain, for example the DirectWrite font proxy on Windows and customized renderer sandbox rules allowing access to the font server on macOS.


 

Note that IPC isn't an issue at all here. All of the renderers on all of the platforms render fine inside the sandbox. It's the font management part (getting the font data to the renderer) that is an IPC concern. The open source stack is nice because FontConfig and FreeType are completely separate libraries that don't conflate the two concepts, unfortunately DirectWrite and CoreText do conflate these ideas into a single library namespace making it difficult to discuss.

Could you clarify what you mean by "IPC isn't an issue at all here." In what sense specifically do you think is IPC not an issue, what do you mean by "here"?

We do require IPC for font matching and fallback on Linux, since we can't run FontConfig inside the sandbox. We will need it for the same purposes on Android with improvements for font matching and font availability that are planned there, since they will only be available as Java API in the host/browser process.

CoreText APIs do their own IPC to the font server behind the scenes, in unsuspecting calls, compare issue 662686. I am not too familiar with the DirectWrite backend, but IIUC the DirectWrite font proxy written by kulshin@ also channels information that DirectWrite needs in-renderer through Chrome's IPC.
  

This issue is not about font lookup, it's about rendering. The title of this issue is "consider FreeType on Windows". IPC is not an issue for rendering. As I stated, font lookup (getting the data into the renderer process) requires IPC, but rendering does not.

re: stability I was lumping e.g. https://goto.google.com/kpboq and crbug.com/561873 in there. We don't know the root cause, but there's still a pretty large number of users affected (200k crashes across 175k clients), a lot more than the 100 clients mentioned in 409784.

Loading any uncontrolled external data file is always going to involve pain and suffering on Windows (regardless of the renderer), but I do feel like we'd be able to take more effective action if we had deeper insight into font loading, selection, and rendering.

(I didn't mean to imply this was higher priority than other work, but I think it could be worthwhile to prototype at some point in a longer term effort.)

Ok, thanks for clarifying the stability data you were referring to.

 Issue 617379  would be first step I guess which is needed either way you wanted to go this path or not.

I don't really see how 617379 is blocking this bug, other than sort of highlighting that without implementing COLR/CPAL support in FreeType we would lose support for this color emoji format on Windows - is that what you mean?

Yes.

Also MacType and GDI++ had interesting experience on this, lots of users were using them when Chrome was using GDI for having freetype rendering and they were providing different settings for their renderer http://cdn.makeuseof.com/wp-content/uploads/2014/09/windows-font-smoothing-mactype-wizard.png?004f0d , something you can use to see which rendering style matches most to current rendering on Mac or Windows so less users would be interrupted by such change.

If we are considering replacing parts of the font system, I would also want to give serious consideration to streamlining the text rendering process overall. Currently, Chrome needs no less than five(!) codebases to render text: DirectWrite to enumerate/load fonts, harfbuzz to do shaping, blink to do layout, skia to draw the thing, and chromium to tie it all together. While each of those does its own thing reasonably well, I think there is definitely potential to streamline the process and reduce the number of parts involved.

Also a note on fallback: although currently on Win the fallback is part of the font proxy (mostly for convenience), it should be straightforward to separate it out. The browser portion would still need to load DWrite, but that should be cheap because it can use the system shared instance. The renderer can then get font names/files and do whatever.

> If we are considering replacing parts of the font system, I would also want to give serious consideration to streamlining the text rendering process overall. Currently, Chrome needs no less than five(!) codebases to render text: DirectWrite to enumerate/load fonts, harfbuzz to do shaping, blink to do layout, skia to draw the thing, and chromium to tie it all together. While each of those does its own thing reasonably well, I think there is definitely potential to streamline the process and reduce the number of parts involved.

I challenge you to do differently :).  Text rendering is surprisingy hard.  We have already cleaned up the shaping part by just using HarfBuzz.  And Skia unifies the graphics part.  However, font discovery still *has* to be system-specific.  We can implement our own and sidestep Fontconfig / directwrite / ..., but that's a large task that needs a lot of thought.  Firefox does that, so there's precedent.  But, I don't think you can go beyond that.  It's a good, not bad, thing, that HarfBuzz, Skia, etc, are separate pieces. They help with keeping our abstractions true and avoid leaky abstractions that will unavoidably ensue if everything was just Blink.

drott@, didn't you just resolve this issue at least partly (yesterday) by making Blink 'fall back' to FreeType for variational font support?  

Did you remove Ben intentionally? Adding bungeman@ again.

> drott@, didn't you just resolve this issue at least partly (yesterday) by making Blink 'fall back' to FreeType for variational font support?

Yes, with emphasis on "partly". 

We can pass decoded web font blobs to Skia for instantiating a FreeType font. We do this as a fallback mechanism as long as we do not have full variation fonts support on Windows, including older versions. This is our architectural choice to bring OpenType variations in Chrome to all platforms.

Still:
* FreeType has a different rasterizer logic, it analytically computes pixel coverages, wheras DirectWrite does "symmetric" (x & y smoothing), and "asymmetric" (x smoothing only) sampling. So, we won't get precisely identical rasterization. Whether that's a problem for our users or not we do not know.
* We do use Windows/DWrite API for for enumeration and font matching and finding fallback fonts, as we do not have our own infrastructure for finding system fonts, except perhaps on Android. And we do not have a replacement for this at the moment.
* etc... :-) There are more aspects that need investigation. The fact that we use FreeType for Variations shows that FreeType based rasterization is possible and can be integrated in a hybrid approach, but whether it's sufficient or desirable as a replacement for all Windows font rendering is open. 

The discussion around  issue 645055 , issue 630917,  issue skia:6432  shows that our users remain very sensitive to font rendering differences.

> shows that our users remain very sensitive to font rendering differences.

I believe they are not unreasonably sensitive, even on the GDI to DirectWrite migration, there wasn't a lot of blow back other than https://www.change.org/p/google-inc-bring-sharp-fonts-back-in-google-chrome-disable-directwrite which is nothing in comparison to Chrome global user base I guess. I remember that even on that case, the main reporter was happy also if he could have freetype and could custom it to his needs. I want also refer you guys again to c#16 story that when Chrome was using GDI, GDI++ came to inject freetype into Chrome rendering, with providing users different options.

So as a practical step forward, I suggest providing freetype enabling flag on Windows and Mac if is possible, I guess that would be best possible step forward to see how it goes.

In fact GDI and DirectWrite are really ugly with custom fonts. I think Chrome should give user an option to switch font render between DirectWrite and FreeType.