Canvas Draw: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 9: Line 9:


It seems, it would be good to start such thing and my 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.
It seems, it would be good to start such thing and my 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.
== Design ==
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
* 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


== Related ==
== Related ==

Revision as of 18:25, 1 December 2018

This article is a stub. You can help the wiki by expanding it.

Background

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 my 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.

Design

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
  • 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

Related

References

References