I don't believe the glyph cache is shared between content processes.
I'm not sure how easy it would be to have shared memory between content processes that could act as the cache.
Regardless, I _suspect_ this lack of caching is impacting the tps test for e10s-multi (see bug 1317312 comment 15). Not 100% sure, but that's what I'm starting to think based on a reading of the profiles in that comment.
You had a suggestion on how we could do some manual counting of certain function calls to prove that the lack of glyph cache is impacting us here. Can you remind me what that suggestion was, exactly?
If you count the global number of calls to SkScalerContext_Mac::generateImage that should give you something to start with.
I added a printf statement here:
Did a single tps run, dumped the output to two logs - single-process.log for a single content process, and double-process.log for 2 content processes.
MacBook-Pro-104:mozilla-central mikeconley$ grep "mconley: SkScalerContext_Mac::generateImage" single-process.log | wc -l
MacBook-Pro-104:mozilla-central mikeconley$ grep "mconley: SkScalerContext_Mac::generateImage" double-process.log | wc -l
So it looks like we're definitely calling it more for 2 content processes.
Is that enough to draw a meaningful conclusion from?
I just talked to jrmuizel. The conclusion we can draw from comment 3 is:
There are some glyphs that are not being shared between the two content processes, and so need to be generated, which is taking time. In single-process, and single-content-process, the glyph cache is shared, so we can save some time.
Two things shake out from this:
1) gabor is going to modify tps so that it does a single pass through of all of the tabs before going through a second time and doing measurement. This is okay because tps is about switching to and painting loaded background tabs - not switching to tabs that we've never seen before.
2) Apparently, WebRender will give us a shared glyph cache, so that's nice.
We're done here.