SVG:Data Storage: Difference between revisions

The strategy currently employed in Mozilla's SVG implementation is to implement the object heavy SVG DOM interfaces in full and store the typed data used by the internal code on those objects. For each attribute that has meaning on a particular SVG element there is always a corresponding DOM object tree in memory - even when the attribute isn't set on the element in the SVG markup. The internal code can then obtains typed data (often default values) as required from these trees since they always exist.

The approach currently used is the obvious one (and it has several non-obvious advantages) but it is inherently very (too) memory intensive. It's made memory intensive not because object trees of typed data are maintained, but because the objects in those trees are XPCOM objects implementing multiple interfaces, and because those trees exist even for non-existant attributes.

We need to come up with a new implementation strategy to drastically reduce our excessive memory consumption while allowing for fast rendering. Unfortunately alternative strategies have significant problems of their own. The rest of this document explains the possible strategies and the problems we need to solve to be able to use them.