Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Data Storage: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 13: | Line 13: | ||
</pre> | </pre> | ||
<!-- | |||
E.g., the SVG 'transform' attribute is mirrored by an SVGAnimatedTransformList object, which contains baseVal and animVal lists of SVGTransform objects, where each SVGTransform owns an SVGMatrix. (Many other attribute values are also represented by different types of object trees such as SVGLength[List], SVGPointList, SVGAngle, SVGColor, SVGPreserveAspectRatio, SVGPathSegList, etc.) | |||
--> | |||
Having so much data crammed into attributes could make it difficult to programmatically access and change much of the data in an SVG graphic. To make that easier, almost all SVG element attributes (data crammed or otherwise) have a corresponding tree of objects full of typed data in the SVG DOM. This eliminates the need for scripters and others to write their own parsing code. However, it presents many challenges to implementers who must provide these object heavy interfaces while minimising memory use and maximising rendering speed. | |||
The problem this document aims to address is how and where to store the typed data. | |||
== Current Implementation Strategy == | |||
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 | 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 | 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. | ||
== | == Alternative Implementation Strategies == | ||
The following strategies assume that parsing data from attribute values whenever it's needed would be too expensive. Therefore we will continue to store typed data associated with SVG attributes in some way. | |||
The strategies also assume we will use tearoffs to implement the interfaces inherited by SVG elements so that their member object trees are only created "on demand". If we aren't to use excessive memory storing typed data in multiple places, the tearoffs and the objects in the trees they create will need to go to their content object for this information. (Duplicating the typed data in SVG DOM objects would also cause nightmarish notification scenarios. Then you would have three sets of potential data to keep in sync, and care would have to be taken not to create a notification loop.) | |||
* | * Strategy A: store the typed value tree directly on the content object as mTransform etc. exactly as we do now. | ||
* Strategy B: store the typed value tree as a member of the nsAttr as we do for properties in a 'style' attribute on HTML content. | * Strategy B: store the typed value tree as a member of the nsAttr as we do for properties in a 'style' attribute on HTML content. | ||
| Line 53: | Line 54: | ||
* What should tearoffs do if they are accessed when there is no corresponding attribute (or after RemoveAttribute has been called)? They could have knowledge of default values, but frames (and probably other code?) will also need to have this knowledge since often attributes and thus their typed object tree won't exist. It seems undesirable to duplicate this knowledge around the source. | * What should tearoffs do if they are accessed when there is no corresponding attribute (or after RemoveAttribute has been called)? They could have knowledge of default values, but frames (and probably other code?) will also need to have this knowledge since often attributes and thus their typed object tree won't exist. It seems undesirable to duplicate this knowledge around the source. | ||
== Issues that are Independant of Strategy == | |||
* How are the tearoffs to access their corresponding typed object trees on the content object? First, how will they get to the right tree? Then how do they identify which item in a tree and/or list corresponds to them? | |||
* How do changes to values of the objects in the typed object trees result in the correct notifications? Does every object in the tree have to keep a pointer to its corresponding nsAttr? Or to its owning content object <b>and</b> corresponding attribute? Or to its owning tree object (notifications to go up the tree first)? | |||
* If the typed date corresponding to attributes is stored on the content objects or their nsAttr objects, what should the objects implementing the SVG DOM interfaces do if the content object is removed from the content tree and consequently deleted? Should an SVGMatrix, say, be left with the values it had? Or should it become the identity matrix as it would if the corresponding attribute was removed? We probably want the former, but how do we support this if the values are stored as a separate tree on the content object? | |||