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 33: | Line 33: | ||
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 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 below also assume we will use tearoffs to implement SVG element interfaces so that their member object trees are only created "on demand". | The strategies below also assume we will use tearoffs to implement the object heavy SVG DOM element interfaces so that their member object trees (the typed data trees that mirror attributes) are only created "on demand". | ||
=== Strategy A === | |||
Store the typed value tree directly on the content object as mTransform etc., similar to the way we do things now. | |||
=== | ==== Pros. ==== | ||
* The typed data is always there (with default values) for the internal code to access. | |||
* | * No GetAttr call required to get to the typed values (unlike strategy B below). Is this a significant saving/issue? | ||
=== Strategy B === | === Strategy B === | ||
Pros. | Store attributes' typed data on their nsAttr similar to the way we do things for the 'style' attribute on HTML content. Every time we want an attribute value or its typed data mirror we'd have to go via GetAttr. | ||
==== Pros. ==== | |||
* Absolutely no memory is taken up for typed data unless the attribute has been set. There aren't even nulled out pointers on the content objects for absent attributes. | * Absolutely no memory is taken up for typed data unless the attribute has been set. There aren't even nulled out pointers on the content objects for absent attributes. | ||
Issues | ==== Issues to Solve ==== | ||
* Will the number of GetAttr calls be prohibitive? | |||
* 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 everywhere else in the codebase where the typed data is accessed would 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 of default values around the source. | |||
== Issues to Solve that are Independant 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)? | ||
* Tearoffs. We have a choice. Do we (a) store typed data on the objects created by tearoffs as well as in the typed object trees maintained by the internal code; or do we (b) have the tearoff objects fetch their typed data from the internal typed object tree that corresponds to them? | |||
* | * If we choose (a) in the above point, this seems a waste of memory. It would also mean we'd have <b>three</b> copies of essentially the same data to keep in sync (ugh! Nightmarish notification scenario with careful design required to make sure we don't have notification loops). How would we do that? | ||
* | * If we choose (a) in the above point, 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? | ||
* 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 | * If we choose (b) in the above point (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? Probably. Or can we just allow it to 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? | ||