The general rule is that the svg module returns OP_STATUS codes. RaiseCondition is used in the textformating in SVGTextLayout and for failed allocations of svg image buffers in SVGImageImpl.
The error if any is returned to the caller via the methods in SVGManager/SVGImage. The svg module does not handle OOM in any other way than returning the error.
The method called to render an SVG image is SVGImage::PaintOnScreen. An SVGImage is generally obtained through the SVGManager::GetSVGImage.
The render call traverses the element tree and performs a number of steps for each elements - most notably enter/handle/leave. If there's a OOM error in any of these steps the error is returned and the stack is restored.
The canvas/svg surface buffers are allocated in heap memory and accounts for the major part of memory usage, [width x height x 4] bytes (since the buffers are always 32bpp). The width and height values are not the calculated width and height, but the width and height of the largest paint received. In addition, one bitmap is allocated to use for blitting the different canvas buffers to the screen/visdev.
SVG attributes are also allocated on the heap, and they vary in size. The paths generated for libvega may be large if the flatness factor (PrefsCollectionDisplay::SVGRenderingQuality) is set too low or if paths are very complex ( = many Beziér curves and/or arcs). The libvega paths are mostly temporary objects of short lifespan, but there are exceptions like motionpaths (used by animateMotion animations, and textPath).
Elements have an associated context (generally an SVGElementStateContext), that is heap allocated and contains element-specific information, such as screen and bounding boxes.
When performing rendering of filters, a number of surfaces are allocated to store intermediate results. The size (and thus the memory usage) of these surfaces are determined by the area in the document being filtered.
During rendering of an svg document, buffers for intermediate results can be allocated (ex: group opacity and pattern handling). The memory consumed by such operations vary greatly depending of the size the area in question.
Document traversal and dependency graph keep state on the heap. There are no very recursive methods in the svg module. Stack memory requirements for the svg module should in general be quite low.
A fixed number of images are cached since it may take some time to re-render an image, this will use [width x height x 4] bytes per image (see Heap memory usage for definition of width/height). The caches can be cleared via methods in SVGManager, and are of course cleared when the SVGManager is destructed. Some other things that are cached: screen boxes (layouted size on screen), glyphs when drawing text.
Methods available to empty caches:
A call to the FreeCachedData() method in SvgModule (OperaModule) will cause all allocated renderers to be deleted.
The SVGManager will return memory and clear all svg caches when destructed. When a HTML_Element tree is destructed it also destructs its attributes, and when a SVG root element is destructed it destructs caches associated with itself.
The SVGTextLayout class uses a tempbuffer (MemoryManager::GetTempBuf2k) to handle text transformations, it's used in the same way as the VisualDevice Txt*-methods use it and the code is structured in a similar fashion. There is a define SVG_TXTOUT_USE_TMPBUFFER that is currently on, that can be turned off to make svg allocate the memory on the heap instead.
The tempbuffer is used only when drawing the text, and the text drawing is only done via calls to the SVGTextLayout class (which is not an exported API). It's guaranteed that the buffer is OK as long as the SVGManager-methods don't return while in the middle of drawing text.
The svg features can be tuned to save some memory. The svg image cache should be rewritten to be tweakable by the module.tweaks-system.
None.
Go through the w3c svg testsuite for example, http://www.w3.org/Graphics/SVG/Test/.
The svg attributes are somewhat more complex than their HTML counterparts since they need to be animatable, meaning it requires some extra footprint. We cache screen boxes of elements so that interaction will be faster, and also for knowing what parts should be cleared when animating. The goal is to paint only changed areas, and as little as possible. The calculations for invalidating an element can be (relatively) expensive if the full area of an image changes all the time, but in general it should be cheaper to do these layout traversals since it's (relative to traversing the tree) expensive to draw the graphics. The formula is subject to change if hardware accelerated graphics support is added.