Canvas-hackers

This article or section contains out-of-date information Please help improve this article by updating it. There may be additional information on the talk page.

Canvas - the FlightGear 2D drawing API
Canvas - Main Page Canvas News - for the latest developments Shiva Alternatives - ongoing work for Core Profile support Canvas FAQs - frequently asked questions Canvas - Getting started Canvas Development (core) Canvas Troubleshooting (core) Canvas Sandbox (core) PUI2Canvas (PUI/XML Parser) Canvas GUI Canvas Widgets Canvas Maps Canvas Snippets
RFC
Canvas Instancing Howto:New Canvas Execution Model Canvas SVG Canvas Popout Windows Canvas Scenery Overlays
Frameworks
Canvas Map API (soon deprecated!) Canvas MapStructure Canvas MapStructure Layers MapStructure Snippets Canvas Radar Canvas Animation Framework (WIP) Canvas Plotting Framework (WIP) Canvas MFD Framework Canvas ND Framework Canvas PFD Framework Canvas MCDU Framework Canvas EFB Framework Canvas Wrappers Canvas Glass Cockpit Efforts
Tutorials
Howto: Canvas Troubleshooting Howto:Adding a canvas to a GUI dialog (PUI!) Howto:Creating a Canvas GUI dialog file (New) Howto:Dynamic Liveries via Canvas (new) Howto:Creating a Canvas GUI Widget Howto:Add a 2D canvas instrument to your aircraft Howto:Parsing 2D Instruments using the Canvas Howto:Creating fullscreen Canvas applications Howto:Use SVG inside a Canvas Howto:Extend the Canvas SVG module Howto:Serializing a Canvas to SVG Howto:Canvas applications as Nasal submodules Howto:Using raster images and nested canvases Canvas HUD Howto:Project 3D to 2D coordinates on desktop canvas
Reference
Canvas Element Group Image Map Path Text Canvas Nasal API MessageBox Layout System Canvas GUI API Canvas draw library Event Handling
Related
Canvas Properties Unifying the 2D rendering backend via canvas Howto:Use a Camera View in an Instrument Howto:Extending Canvas to support rendering 3D models Howto:Extending Canvas to support MathGL
To be ported
Navigation display Map FGCanvas Canvas Nasal/JavaScript Subset
Deprecated by Canvas
Complex Glass Cockpit Avionics
(click on headings to toggle)

The Canvas-hackers team clone on gitorious is intended to streamline collaboration among FlightGear contributors who are doing Canvas related development intended to be merged into upstream fgdata, especially related to long-term efforts to help Unifying the 2D rendering backend via canvas such as:

We originally set this up to allow non-fgdata committers to commit canvas related contributions to a single repository - since then, MapStructure development has stalled a bit. These days, it's primarily artix who's been doing most related development. Originally, the idea was to regularly sync back useful changes so that they appear in the "upstream" fgdata repository. Since then, quite a few things have changed - including the fgdata/fgaddon split, but also gitorious shutting down, which is why we're lagging a bit behind. Also, gitorious announced that they'd shut down all repos at the end of May IIRC - but it seems quite a few repositories/projects are already no longer reachable unfortunately. So there's that too. — Hooray (Sat Apr 04). Re: new locatio of Canvas-hackers-fgdata branch?. (powered by Instant-Cquotes)

• Canvas EFIS Framework (2020/02): jsb
• Canvas MapStructure (2013/2014: Philosopher & Hooray)
• NavDisplay (2013/2014: Gijs, Hyde)
• Canvas GUI (2013-2015: TheTom)
• Canvas MCDU Framework (2012: TheTom)

---

While there is a Mailing list, in comparison to the forum, it's fairly inactive these days and it's primarily about C++ level CORE development.

For Canvas related things, we often also discuss core changes on the forum, because we have a dedicated subforum here, and because TheTom, as the main Canvas core developer, is very active on the forum and usually handles support requests or feature requests pretty promptly.

Regarding wiki articles and Canvas related priorities. the focus/manpower is mostly on 1) re-implementing our existing GUI on top of Canvas through custom (scripted) widgets: Canvas Widgets (mostly handled by TheTom & Zakalawe, both of them core devs).

And then, we're busy re-implementing existing hard-coded "glass" instruments using Canvas, i.e. stuff like the ND, PFD etc.

For that, we try to generalize, unify and extend existing code and make it use Canvas, by coming up with custom scripting-space frameworks for the main use-cases. This includes things like having a dedicated Canvas Animation Framework that deals with SVG elements and animations handled via timers and listeners.

But also frameworks for other MFD related purposes, such as: 1) MFDs in general, 2) PFDs, 3) NDs, 4) CDUs and 5) EFBs These are intended to be just tiny wrappers to help localize key functionality (e.g. MFD page/mode handling), so that we can easily update and optimize things, without having to touch a ton of places (aircraft/instruments/dialogs).

The long-term idea is to provide scripted frameworks on top Canvas, e.g. for MFDs - and each kind of MFD would implement the corresponding MFD interface.

Canvas-wise, the main trend is to increasingly modernize and unify our 2D rendering back-end by adopting canvas in several key areas by Unifying the 2D rendering backend via canvas:

• glass instruments (ND/PFD)
• 2D panels/instruments
• HUDs
• GUI dialogs/widgets

We have 3 core developers and a handful of Nasal/Canvas contributors working towards this - so this is generally considered a useful thing, and several active contributors are working towards the same goal here .

At the Canvas core/C++ level, there are some minor enhancements discussed/planned: Canvas Development. But anything touching the C++ code should really be coordinated with TheTom.

So you can basically "pick your poison" - feel free to ask via the canvas forum for more opinions/pointers and feedback.

Otherwise, there's also an issue tracker - and various wiki articles on getting started contributing/coding.

For the time being there's quite some manpower in Canvas related effort - and it allows us to get rid of a ton of legacy C++ code, while also modernizing FG quite a bit, i.e. to obtain better frame rates, a more modern GUI, better consistency etc.

Should you be interested in working on anything related to Canvas, we have people willing to provide mentoring through custom tutorials etc (get in touch with Hooray).

The priorities are mostly those mentioned above, and there are core developers willing to commit related stuff. We'd just suggest to make sure to release early & often, so that you can gather & implement feedback early on.

Feel free to get in touch via the canvas forum to get more pointers.

We'd suggest to get started with just Nasal/Canvas, because there isn't much of an entry barrier - and we're still looking to port a few layers: Canvas MapStructure Layers: We have a few "old" layers that do not yet use the new system, i.e. they work already, but are not yet ported - which would be good for performance reasons. That is something that we would help with, and also "mentor", because it would be useful for FG as a whole, because all MapStructure layers can be used on all aircraft/dialogs, so not aircraft specific. The MapStructure Layers article should provide a rough overview.

The lowest hanging fruit there would be porting the "tower.draw" file to become a MapStructure layer with a proper lcontroller/symbol file. That one should be even simpler than the AA work. "Parking" would be another simple layer to get started.

• $FG_ROOT/Nasal/canvas/map/tower.draw
• $FG_ROOT/Nasal/canvas/map/parking.draw
• we're also missing an ILS/LOC layer that draws a localizer symbol (see Map)
• $FG_ROOT/Nasal/canvas/map/runway-nd.draw also hasn't yet been ported to MapStructure

And then there are 3-4 others that will undoubtedly require a little more help from our side (e.g. runways.draw, taxiways.draw), but otherwise it should be straightforward, and a good exercise to learn more about creating your own maps/charts - which should also come in handy for any more sophisticated efforts.

Some of the more sophisticated layers actually make use of customizable styling and caching - depending on the nature of the layer (e.g. static vs. moving objects), it makes sense to keep such things in mind. Another important consideration is LOD handling, i.e. changing the symbol based on the map's range. Another thing we're not currently dealing with is centralized labeling and decluttering.

In the near-term, it would also make sense to better encapsulate properties that may be aircraft specific, or that would break when used with an AI aircraft, i.e. all references to properties provided by the autopilot, route manager, weather system or radios/instrumentation. We really want to support independent instances, no matter how often the framework is used concurrently - for example, see the following forum posting demonstrating how the ND is driven by AI traffic[1].

Also, in the process, we'd like to improve the wiki docs accordingly - because our goal is to provide all the docs to enable newcomers to create their own mapping layers.

But for starters, creating/porting a few MapStructure layers should be a good learning exercise, and the whole experience should help you once you want to get involved in other Canvas areas.

Note  People don't need to have fgdata commit privileges to contribute. However, you should obviously know a little about Nasal scripting, OOP and Canvas. We're hoping to regularly sync our work with fgdata upstream - realistically, that ones once in 6-8 weeks probably.

Branch	Description	Status	Schedule	People	Notes
canvas-map-dialog	Port the hard-coded Map dialog to Canvas		Hopefully 3.2	Philosopher & Hooray	...
topics/fgplot	2D plotting		Hopefully 3.2	kuijfe09	...
canvas-airports-dialog	Port the airport-selection dialog to Canvas		unknown	Philosopher & Hooray	...
yet to come	Garmin gpsMap196 ported to Canvas		unknown	F-JJTH [2], Hooray	...
yet to come	Procedurally-created Canvas GUI dialogs for A Failure Management Framework for FlightGear	Not done	unknown	Galvedro, Necolatis, Hooray	...