SVG:Data Storage: Difference between revisions

Feel free to edit this document as heavily or lightly as you want, but please try to keep comments explicitly denoted as having being made by you to a minimum. People are reluctant to remove such comments, and this prevents documents from evolving into a spec/final documentation because they just become an unmanageable mass of comments no on will touch. Instead try to integrate your comments into the flow of the document where possible. Do a significant rewrite if necessary.

One of the ways in which the SVG specification stands out from other W3C XML specifications is the extent to which it crams lots of data into attributes. For example, it's not uncommon to see an SVG file containing a <path> tag with a 'd' attribute (for the path data points) similar to the following:

Having so much data crammed into attributes makes it difficult to programmatically access and change much of the data in an SVG graphic using get/setAttribute. To make that easier, almost all SVG attributes (data crammed or otherwise) are mirrored by multi-level trees of objects in the SVG DOM which contain typed data corresponding to the attributes' values. This eliminates the need for scripters and others to write their own parsing/serializing code for attribute values. However, it presents challenges to implementers who must provide these object heavy interfaces while minimizing memory use and maximizing rendering speed.

The strategy currently employed in Mozilla's SVG implementation is to implement the object heavy SVG DOM interfaces as full objects 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 obtains typed data (often default values) as required from these trees since they always exist.

We need to come up with a new implementation strategy to drastically reduce our excessive memory consumption while allowing for fast rendering and declarative animation. Of course each strategy has significant implementation problems of its own. The rest of this document describes possible strategies and the problems we need to solve.