SVG:Cleanup: Difference between revisions

Jump to navigation Jump to search
m
fix link to SVGDev:Animation
(more work could be done to put fields in a better order)
m (fix link to SVGDev:Animation)
Line 15: Line 15:


Each animated length currently (actually animated or not) requires a bundle of XPCOM objects. I have a proposal to shrink this to a single 8-byte struct in the non-animated case.
Each animated length currently (actually animated or not) requires a bundle of XPCOM objects. I have a proposal to shrink this to a single 8-byte struct in the non-animated case.
I have a proposal for this on the wiki at [[SVGDev::Animation]] which I won't repeat here. The basic idea is to store coordinate data efficiently as fields of SVG content objects. DOM access is provided by creating tearoffs holding a reference to the content object holding the coordinate and the index of the coordinate within the content object.
I have a proposal for this on the wiki at [[SVGDev:Animation]] which I won't repeat here. The basic idea is to store coordinate data efficiently as fields of SVG content objects. DOM access is provided by creating tearoffs holding a reference to the content object holding the coordinate and the index of the coordinate within the content object.


As part of this, instead of having frames hold references to relevant coordinates, they would get the data through content every time it is needed, by casting their content element to the appropriate *concrete* SVG element class.
As part of this, instead of having frames hold references to relevant coordinates, they would get the data through content every time it is needed, by casting their content element to the appropriate *concrete* SVG element class.
Confirmed users, Bureaucrats and Sysops emeriti
969

edits

Navigation menu