Jump to: navigation, search

Canvas SVG Parser

1,567 bytes added, 02:48, 17 January 2015
Vector Image Support:
=== Vector Image Support ===
The SVG parser basically just maps the xml structure to the property tree. It is implemented in Nasal on top of the XML parsing facilities already provided by FlightGear. Using separate canvas elements instead of a single image will always be slower as every little piece of the canvas hat to be triangulated and afterwards rendered every time the canvas gets updated instead of just copying an image. On the other hand you if you use the canvas you can dynamically update the contents of the image and also get (theoretically) unlimited resolution, even changeable at runtime. For SVG, already existing tools (Inkscape) can be used to create images and then just load them via Nasal and add some dynamic features to them.
If you find some SVG feature not working, please check the console for errors - our SVG parser is hand-written and only supports a limited subset of SVG instructions, so may need to be extended, or simply use supported inkscape primitives instead (see svg.nas). $FG_ROOT/Nasal/canvas/svg.nas is our existing example on populating a canvas procedurally by parsing an XML file.
Basically, it looks for supported SVG primitives, and turns those into Canvas/OpenVG primitives by setting properties.
The SVG standard explicitly supports referencing other images (including raster images and SVGs) via the "image" tag - even recursively, so I'd be surprised if inkscape didn't support that. However, our svg parser doesn't currently support this IIRC - but it's "just" Nasal code, so would probably just require ~10-15 lines of code to add support for the image/object tags.
the svg parser is hand-written and can be found in $FG_ROOT/Nasal/canvas/svg.nas, it can be easily extended to support additional primitives/tags, you just need to map them to the corresponding OpenVG equivalents, I think supporting shapes would make sense and shouldn't be too difficult.
our svg.nas parser could also be extended to support external SVGs directly, i.e. using the <use> and <image> tags. The other concern here is performance - once instruments are self-contained and can be treated as such, we can also update them more selectively, i.e. we don't necessarily have to use timers for each individual element, but can instead update instruments in a holistic fashion.
<!-- Integration-wise, there are some lessons to be learnt from the way SMIL works via SVG and ECMAScript (JavaScript). -->

Navigation menu