SVG:Cleanup
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.
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.
Fix (animated) lengths
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.
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.
Don't create unnecessary CSS rules
Only create a CSS rule for an SVG element if the SVG element actually has at least one persentational attribute ... should be easy.
Eliminate PRBool fields
PRPackedBool should be used for fields, and fields should be ordered to minimize padding.
Fix nsAutoVoidArray field
Use nsVoidArray or nsSmallVoidArray in fields instead.
Eliminate duplicated code
There is much duplicate code. Stuff that I've noticed:
- GetCanvasTM() implementations
- Paint() implementations duplicate code for filters, clipping etc
These simply requiring moving code to nsSVGUtils or possible an SVG frame superclass.
deCOMtaminate core data structures
SVG points and matrices are currently always XPCOM objects, and even C++ code goes through the DOM interfaces to manipulate them. Consequently even something as simply as transforming a point with a matrix requires a heap allocation. SVG point and matrix types (and possibly others I haven't encountered yet) should either be converted to non-virtual C++ objects (possibly just using the Thebes gfxPoint and gfxMatrix types), and a DOM tearoff system used similar to my proposal for lengths, or else can remain XPCOM DOM objects but have SVG C++ code cast them to their concrete class for efficient access.
Eliminate extra vtable pointers by removing multiply inherited interfaces
The above changes should eliminate the need for many of the interfaces on frames and content. In many other cases we could use a concrete (super)class instead of an abstract interface. In some limited cases we might have to push a set of methods into a superclass even though some of the methods are not implemented in some subclasses; this violates XPCOM/OO purity but reducing the number of vtable-pointers in each object, and reducing the number of QIs, is probably worth it.
Eliminate mostly-unused fields
Consider using a property system or some other technique so that SVG content elements and frames don't have to carry references to a tranform list, filter, fill gradient, etc unless they actually have one.
DeCOMtaminate non-DOM interfaces
Interfaces that are not exposed to script need not, and should not, follow XPCOM method guidelines; their methods should be as close to C++ style as permits.
Remove GDI+/libart renderers
Trivial code removal, followed by conversion of renderer abstract interfaces to direct usage of the cairo renderer classes, followed by ...
DeCOMtaminate/devirtualize cairo/Thebes renderer
Self-explanatory.
Reconsider nsSVGCairoRegion
nsSVGCairoRegion is just a rectangle; dump it unless a reason exists to fix it.