1,295
edits
SVG:Cleanup: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
|||
| Line 2: | Line 2: | ||
[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. | [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. | ||
[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. | |||
==== Eliminate dynamic observers ==== | ==== Eliminate dynamic observers ==== | ||
| Line 7: | Line 9: | ||
[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? | [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? | ||
[roc] That patch is very good stuff. I would use GetPrimaryFrameFor for whatever's left. The first use on a given element-frame pair is slow, but after that I believe it's just a hashtable lookup. I would want to see a detailed scenario where GetPrimaryFrameFor is too slow before trying someting bloatier/more complex. | |||
==== Fix (animated) lengths ==== | ==== Fix (animated) lengths ==== | ||
| Line 21: | Line 25: | ||
[tor] We'll need guidance from a style person regarding this. | [tor] We'll need guidance from a style person regarding this. | ||
[roc] I could be wrong but I think it's really simple. See [[http://lxr.mozilla.org/seamonkey/source/content/svg/content/src/nsSVGElement.cpp#611]] | |||
==== Eliminate PRBool fields ==== | ==== Eliminate PRBool fields ==== | ||
| Line 90: | Line 96: | ||
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. | 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. | ||
[roc] yeah, this sounds logical to me. I was wondering why you don't do this already but I thought there might be a good reason. Glad I was wrong :-). | |||