49
edits
SVG:Cleanup: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| 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> ([[SVGDev:Use]]) in hand when doing this work, to make sure we aren't going down the wrong path. | |||
==== Eliminate dynamic observers ==== | ==== Eliminate dynamic observers ==== | ||
Figure out what the observer structure actually is, and hardcode it with notification methods. It seems to me that most notifications flow from coordinate objects to their frames. My suggestion is to have the SVG content objects notify SVG frames directly on relevant attribute changes and DOM calls. Style changes already reach the frames. When irregular notifications are required (e.g., gradients notifying their users), we can have an explicit observer list for just those objects that need it. As long as observers are limited to frames, don't use XPCOM weak references for the observer pattern. Frames are explicitly created and destroyed, and you can remove the observer relationship whenever the observer or the observee is destroyed. | Figure out what the observer structure actually is, and hardcode it with notification methods. It seems to me that most notifications flow from coordinate objects to their frames. My suggestion is to have the SVG content objects notify SVG frames directly on relevant attribute changes and DOM calls. Style changes already reach the frames. When irregular notifications are required (e.g., gradients notifying their users), we can have an explicit observer list for just those objects that need it. As long as observers are limited to frames, don't use XPCOM weak references for the observer pattern. Frames are explicitly created and destroyed, and you can remove the observer relationship whenever the observer or the observee is destroyed. | ||
[tor] The patch in bug 301628 took a first step down this route by removing most explicit use of SVG observers in the SVG frames, replacing them where needed by the AttributeChanged mechanism. How do you intend that the content objects notify the SVG frames? Via GetPrimaryFrameFor(), which I've been warned away from in the past due to it being a relatively heavyweight operation? | |||
==== Fix (animated) lengths ==== | ==== Fix (animated) lengths ==== | ||
| Line 15: | Line 19: | ||
Only create a CSS rule for an SVG element if the SVG element actually has | Only create a CSS rule for an SVG element if the SVG element actually has | ||
at least one persentational attribute ... should be easy. | at least one persentational attribute ... should be easy. | ||
[tor] We'll need guidance from a style person regarding this. | |||
==== Eliminate PRBool fields ==== | ==== Eliminate PRBool fields ==== | ||
| Line 80: | Line 86: | ||
nsSVGCairoRegion is just a rectangle; dump it unless a reason exists to | nsSVGCairoRegion is just a rectangle; dump it unless a reason exists to | ||
fix it. | fix it. | ||
=== [tor] Build up CTM incrementally during rendering === | |||
Currently the CTM for each object being rendered is calculated by walking recursively up the tree to an nsSVGOuterSVGFrame, then combining the matrixes. This made sense for the libart and GDI+ renderers which operated in retained mode so this calculation only needed to be redone when the object changed. In the cairo immediate mode world it makes more sense to build up the transform as we walk down the tree rendering. | |||