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 3: | Line 3: | ||
== Introduction == | == Introduction == | ||
One of the ways the SVG specification | One of the ways in which the SVG specification stands out from other W3C XML specifications is the extent to which it crams a lot 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: | ||
<pre> | <pre> | ||
| Line 17: | Line 17: | ||
--> | --> | ||
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 attributes (data crammed or otherwise) | 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 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 code. However, it presents 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. | The problem this document aims to address is how and where to store the typed data. | ||
| Line 23: | Line 23: | ||
== Current Implementation Strategy == | == Current Implementation Strategy == | ||
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 can then | 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 can then obtain typed data (often default values) as required from these trees since they always exist. | ||
The strategy currently used is the most obvious and straightforward one (and it has several non-obvious advantages) but it is inherently very (too) memory intensive. It's made memory intensive not because trees of objects and 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. | The strategy currently used is the most obvious and straightforward one (and it has several non-obvious advantages) but it is inherently very (too) memory intensive. It's made memory intensive not because trees of objects and 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. | We need to come up with a new implementation strategy to drastically reduce our excessive memory consumption while allowing for fast rendering. Of course each strategy has significant implementation problems of their own. The rest of this document describes possible strategies and the problems we need to solve before we can use them. | ||
== Alternative Implementation Strategies == | == 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 | 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 mirroring SVG attributes in some way. | ||
The strategies also assume we will use tearoffs to implement | The strategies below also assume we will use tearoffs to implement SVG element interfaces 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 A: store the typed value tree directly on the content object as mTransform etc. exactly as we do now. | ||