Canvas PFD framework

Canvas PFD Framework

Started in	not yet...
Description	PFD Framework
Contributor(s)	Hooray (if nobody beats me to it),
Status	discussion
Subforum	http://forum.flightgear.org/viewforum.php?f=71

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

Canvas - the FlightGear 2D drawing API
Canvas - Main Page Canvas News - for the latest developments Shiva Alternatives - ongoing work for Core Profile support Canvas Efforts - projects using the Canvas system 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:Getting started with Canvas 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)

Background

Zakalawe:In terms of the EADI I haven't thought about structure at all - if there is a system to use, point me at it. Certainly for the .nas file which drives the PFD & EADI, I would expect it to be 99% the same (just needs to handle missing elements better) - and likely is very similar for all PFD-type displays including Airbus and G1000. I don't think using a single global SVG file is going to work - the problem is this is a totally different technology generation to the 747-400 / 777 / 737-NG displays, so although the symbols are similar, the actual appearance is different. Maybe 'new Boeing' and 'old Boeing' files would work? Since the 737-Classics, 757 and 767 all use this earlier style of EADI. (And similarly the EHSI is a simplified version of the ND). Anyway, as I said, my interest is to get some working - if someone provides a 'system' I'll use it but I'm not interested in writing it myself

Maybe you could make a system where symbols can be grouped arbitrarily in SVG files, and layered together? Eg one layer for the speed-tape, one for the altitude-tape, one for the horizon. (Does Inkscape support including a layer from another SVG file?). Since I agree being able to position elements visually is very nice.

Hooray:What exactly are your Nasal/coding plans related to Gijs' PFD code ? I am asking because I mentioned a couple of times that I was hoping to look into it as some point, specifically with the intention to make things as portable and as flexible as the ND framework - i.e. to support at least multiple independent instances per aircraft, but also support different types of aircraft (beyond just Boeing and Airbus). Obviously, this requires a fair deal of generalizing things and getting rid of hard-coded assumptions. The other use-case that the ND code now supports is easily rendering these instruments in GUI dialogs, no matter if these are PUI widgets or "native" Canvas windows. Basically, my idea was to generalize the ND code some more and come up with helper classes for 1) SGSubsystems, 2) MFD instruments and 3) image generators, 4) displays and display switches/selectors. Introducing a handful of helper classes would allow us to support all important use-cases that are common in modern glass cockpits, including switching between different FMCs or PFDs/NDs.

Hooray:Overall, removing SVG elements to come up with custom SVG files is not such a good idea - the approach taken by the ND module is to have a common/shared SVG file for different types of NDs, with added symbols for different types of aircraft - these are loaded into canvas groups, i.e. can be trivially animated, but also shown/hidden. The long term idea here being to encourage developers to maintain a single SVG file that lives within $FG_ROOT, rather than within $FG_AIRCRAFT - so that we can grow a library of symbols and different "styles" (themes) - for different types of aircraft and glass cockpit systems.

This approach is also favored by Gijs and Hyde.

In general, we really don't want to see a ton of custom files for different aircraft, no matter if this is a ton of Nasal spaghetti code, or custom SVG files - these PFDs are similar enough to be driven by a common generic back-end, using symbols from a single SVG file with different groups/layers. The way the ND code has been reworked, makes it possible to factor out custom stuff into helper hashes, which animate a single element independently - this can be triggered via listeners, timers - or permanently run via polling in a single update() loop.

Generalizing Gijs' PFD code accordingly would probably take 2-3 weekends, integrating and unifying this with the ND "framework" would be another 2-3 weekends. I would really prefer to closely coordinate things here - we really don't want to have people come up with hugely different approaches for different types of MFDs.

TheTom:I'm not sure if it is really a good solution to use a single svg files with all possible PFD elements and combine them (from Nasal?). We could to a collection of elements and copy them together, but there are so many different types of layouts that it will not be possible to cover every possible visualization. Also positioning and resizing the elements is much easier and faster from within InkScape. A common framework in the background (with some common elements like "rotating" numbers, HSI logic, trend vector calculations, etc.) is definitely a good idea.

Hooray:When we came up with the idea of sharing a common SVG file, this was primarily about the Boeing series of airliners (747, 747, 777, 757 etc) - the point being that we want to avoid unnecessary duplication of functionality - if we introduce separation too early, things are likely to be adopted in a "copy & paste" fashion probably - that's in fact how Hyde started adapting Gijs' 747 ND for use in the 777, and neither Gijs or myself were really thrilled about it. As a compromise, I would suggest to maintain manufacturer specifics SVG files instead - i.e. either based on aircraft manufacturers (Boeing/Airbus) or based on EFIS manufacturers like Honeywell. Overall, I would just suggest not to separate things too early - or people are going to end up using lots of "copy & paste" to implement certain features. FG development isn't overly organized - so we basically need to "force" people to generalize things by adopting a corresponding framework that encourages generalization at its core. But I can perfectly understand that the C130J would not be well served by a Boeing or Airbus-based SVG file... so better grow a "library" of symbols for different manufacturers, but ensure that this does NOT live within $FG_AIRCRAFT