Our font cache seems completely broken to me. The cache keys are family names, which is wrong, but even if it was not, a Web font source could change between 2 requests so we can't use the source as key.

@pcwalton @glennw Would it be bad to just store Web fonts in the layout thread? How then would we feed them to the font context of the paint thread?

@nox It's not thread to thread. In multiprocess, painting happens in the privileged process and layout in unprivileged. So this will cross a process boundary.

@nox The font cache being completely broken aligns with what I've seen, namely that nytimes.com fonts can be totally random.

@nox The idea of storing web fonts in the layout thread sounds quite good. I haven't thought through all the details, maybe there are some gotchas, but it does sound worthwhile. With webrender, layout just needs to pass the font once via a message when it first receives the font, so that should be easy enough. Any thoughts on that idea @pcwalton ?

@metajack Where could I store font handles and be sure that they will be freed on tab navigation, when the font is not needed anymore, etc? How painting, layout, script and style communicate is still quite vague to me.

There is a limit to how many pipelines will be retained even when they are non-active. When they are freed, script and layout will both be shut down.

The only case I'm not 100% clear on is what happens when a script thread is reused. Does layout get rebuilt or just start receiving new display lists? If the latter, that could be a case where we would hold onto fons (if stored in layout) longer than we want.

Layout threads are never reused.

@jdm Great. What's the lifetime for the paint threads in all that? They don't run in the same process as layout right? So we need to have life font handles in two separate processes, am I wrong?

Correct, paint and layout threads run in different processes, but should have approximately the same lifetime.

Paint threads will not exist once WR becomes the only renderer. And the WR renderer will have basically a static lifetime.

@metajack Will the WR renderer need to do things with fonts, or will everything that is font-related live in layout?

WR needs font data to rasterize glyphs. Layout needs font data to determine where glyphs will appear and to calculate inline length. They both need it for different purposes.

So we need an invalidation mechanism in WR too, right? Doesn't that mean that at least part of the font cache (and probably HTTP cache) need to live outside of Servo, given WR itself lives outside of Servo?

WR will in theory be in another process.

I suppose we can either a) put the cache in the privileged process or b) put a cache in each process. In the (b) option, we'd just send the font data along with the display list and WR could cache it there. Or if the font is local font, we could just send an identifier so it can be loaded there and then cached.

cc @glennw @pcwalton

@pcwalton It seems that on IRC you mentioned we could make a Weak-like version of OsIpcSharedMemory, especially with mach ports, but I don't see how you can get notified that a vm_allocate'd blob has been freed by everyone.