Confirmed users, Bureaucrats and Sysops emeriti
969
edits
SVG:Cleanup: Difference between revisions
Jump to navigation
Jump to search
killing SVGDev
m (SVGDev:Cleanup moved to SVG:Cleanup: killing SVGDev) |
(killing SVGDev) |
||
| Line 1: | Line 1: | ||
Some suggested improvements to make the SVG code smaller, simpler, and much more efficient. See http://weblogs.mozillazine.org/roc/archives/2006/02/anatomy_of_bloat.html for some context. These are roughly in order of apparent priority. | Some suggested improvements to make the SVG code smaller, simpler, and much more efficient. See http://weblogs.mozillazine.org/roc/archives/2006/02/anatomy_of_bloat.html for some context. These are roughly in order of apparent priority. | ||
[tor] It would be good to have a design solution for <use> ([[ | [tor] It would be good to have a design solution for <use> ([[SVG:Use]]) in hand when doing this work, to make sure we aren't going down the wrong path. | ||
[roc] I believe all these suggestions are compatible with the multiple frames approach, modulo the fact that the multiple frames approach requires some work to allow for multiple primary frames per element (one per independent rendering), and stuff below would have to be modified to suit. | [roc] I believe all these suggestions are compatible with the multiple frames approach, modulo the fact that the multiple frames approach requires some work to allow for multiple primary frames per element (one per independent rendering), and stuff below would have to be modified to suit. | ||
| Line 17: | Line 17: | ||
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 [[ | I have a proposal for this on the wiki at [[SVG:Notification_Mechanisms]] 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. | ||