Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Canvas Draw

From FlightGear wiki
Revision as of 14:32, 1 December 2018 by Hooray (Talk | contribs) (Background: https://sourceforge.net/p/flightgear/mailman/message/35611240/)

Jump to: navigation, search
This article is a stub. You can help the wiki by expanding it.


By now, Thorsten created a library of procedural commands which allows you to e.g. draw a HUD with a minimal set of commands and re-draw it with a different design if you find it doesn't match reality runtime - something which SVG can just not do.

All it needs is to streamline it and document it, and then the situation your describe may (or not) change, but in Thorsten's opinion it beats SVG in designer-friendliness by a large margin - simply because you can change spacings etc. runtime in FG. Whereas re-drawing a pitch ladder with different spacing in SVG is a piece of work and there's no guarantee you get it right runtime.[1]


a library of functions to draw more complex things on a canvas? While some people prefer Inkscape/SVG and others prefer nasal scripting, this page is intended to document a library for procedural drawing.

Specifically, to help implement elements commonly used for the PFD and parts of MFD.

While people can certainly find lots of code in all the different aircraft for drawing things like speed tape, compass, engine instruments etc. but as far as I see there is nothing like a canvas.draw library as of 12/2018.

It seems, it would be good to start such thing and the first elements would be a compass rose and a linear tape (e.g. for speed and altitude), stylable of course. So the library should also contain a structure to organize styles.

Existing work

TODO: add links

  • shuttle 2D drawing helpers (Thorsten)
  • rleibner's 2D drawing API
  • extra500 helpers

(anything else ?)


Ideally, the new 2D drawing helpers would be agnostic to the concrete use-case, so that they can be used for arbitrary purposes. This can be accomplished by following a few simple design principles:

  • all drawing callbacks should accept a mandatory group/element node to operate on
  • all drawing callbacks should accept/support an optional options hash
  • all drawing callback should return the corresponding Canvas element

This would be in line with the existing Canvas/MapStructure APIs, and it would also make it possible to easily use delegates to customize internal behavior


We are proposing a layered design, with simple shapes being used to implement more complex elements (think altitude/speed tapes, artificial horizon etc). Internal default heuristics should be customizable via delegates (Nasal callbacks).