Open Bug 1496583 Opened 3 years ago Updated 11 months ago
[Fission] Memshrink: Consider sharing SVG resource documents across content process
There are at least a couple of issues that would make sharing resource documents between processes "non-trivial". First, our layout code currently accesses SVG resource documents via direct access to their frame trees. That would clearly need to change. Second resources are not read-only. We currently call NotifySVGChanged(nsSVGDisplayableFrame::TRANSFORM_CHANGED) on the frame tree to set some mCurrentTM state just before recursing into the painting code for a resource. We could fix that in some sort of shared representation of resources, but then there's still CSS animations etc. Those may pose a problem depending on whether we were to share an animating representation, or just declarative data describing animations. It would be useful to have some stats on how common resource documents are, whether they're often shared across origins, and perhaps on which element types and attributes are used.
It seems to me like the simplest option for resource documents would be: 1. keep the resource document cache being per-process, just like it is now (though still on top of the cross-process network cache) 2. allow cross-origin resource documents within the process for a different origin, if that origin references those documents, just like we do for cross-origin scripts, etc. If we want to do something more than that (particularly as a blocker for the initial fission release), I'd be interested in understanding both what it is, and the motivation for it.
Priority: P3 → P5
Summary: [Fission] Figure out how to share SVG resource documents across content process → [Fission] Memshrink: Consider sharing SVG resource documents across content process
Fission Milestone: --- → ?
Fission Milestone: ? → Future
You need to log in before you can comment on or make changes to this bug.