1496583 - [Fission] Memshrink: Consider sharing SVG resource documents across content process

Status: NEW

(Core :: Layout, enhancement, P5)

Description

[Jonathan Watt [:jwatt]]

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 2

[Chris Peterson [:cpeterson]]

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

Comment 3

[Chris Peterson [:cpeterson]]

Future perf