Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Data Storage: Difference between revisions
Jump to navigation
Jump to search
fix spelling
No edit summary |
(fix spelling) |
||
| Line 1: | Line 1: | ||
Feel free to edit this document as heavily or lightly as you want. Please try to keep comments denoted as explicitly being made by you to a minimum though. (People are reluctant to remove such comments, and this prevents documents from evolving into a spec/final documentation because they just become an | Feel free to edit this document as heavily or lightly as you want. Please try to keep comments denoted as explicitly being made by you to a minimum though. (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. | ||
== Introduction == | == Introduction == | ||
| 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) 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 | 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 minimizing memory use and maximizing 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 25: | Line 25: | ||
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 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- | 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-existent attributes. | ||
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. | 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. | ||
| Line 63: | Line 63: | ||
It seems undesirable to duplicate knowledge of default values around the source. It raises the potential for defaults being right in some instances and wrong in others. | It seems undesirable to duplicate knowledge of default values around the source. It raises the potential for defaults being right in some instances and wrong in others. | ||
== Issues to Solve that are | == Issues to Solve that are Independent of Strategy == | ||
* 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 nsAttr? Or to the object above it in the typed data tree (so notifications go up the tree)? | * 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 nsAttr? Or to the object above it in the typed data tree (so notifications go up the tree)? | ||