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 EFIS Framework

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


Canvas EFIS framework is work in progress. I (jsb) am working on this for the CRJ700 family. For now, this page will contain design drafts and ideas.

For the bigger picture see also Howto:Add an EFIS to your aircraft.

Design draft

Some assumptions:

  • More than one display unit (DU), e.g. a common airliner config would be six DU: 2x PFD, 2x MFD, 2x EICAS
  • Transfer of display sources to different DU so the pilot can handle display faults
  • Multiple pages per display role, e.g. for EICAS
  • Allow EICAS pages to be shown on different / multiple DU (the Rockwell Collins used in the CRJ700 supports this)

The EFIS framework should provide nasal classes to handle the following:

Display unit

  • reference to a 3D object in the cockpit ("display unit") on which the canvas texture shall be displayed
  • power switch property
  • dim property
  • image source (canvas reference)

Image source

  • base class for EFIS/EICAS pages handling some SVG stuff
  • Should be easy to configure, e.g. by providing some common listeners to show/hide or colorize elements

Display selectors / routing

  • Handle input events from cockpit knobs to switch displays / pages

EICAS Message system

  • Handle EICAS messages efficiently without eating up to much frame rate
  • Message queue: decouple canvas updates from message arrival
  • semi-automatic listener setup

Thoughts on implementation

Claim: EFIS framework should support different update rates / methods for efficency.

Update rates

The EFIS/EICAS basically monitors the whole aircraft so it will have to read lots of properties. For efficency the properties must be grouped into classes already in the design phase, that is, the aircraft developer shall carefully think about how often a property changes. Some props are written to at frame rate by property rules but that does not mean the value changes every time. Furthermore, not every change has the same relevance, not everything needs to be displayed real time (real time = frame rate).

update rate Interval comment
2 0.500s low performance needs
10 0.100s low to med. performance but no fluent animation
20 0.050s
30 0.033s smooth canvas animation but possibly high performance need
60 0.017s

Some examples:

  • PFD contains many "real-time" elements like attitude indicator, speed, altitude etc. They should be updated probably at frame rate (min. 25 Hz) Other elements like radio frequency may be ok to update after 100ms or even 0.5s
  • An EICAS page displaying the door status maybe just fine with one update per second as doors move slowly and you won't see the door from outside and EICAS display inside the cockpit at the same time so a delay of one second does not matter

Update methods

  • Simple approach is to write an update loop that reads all relevant props, calculates the needed updates and updates the canvas elements (which in the end means writing properties).
  • Property read/write is somehow "expensive" and can cost you a lot of framerate. So the next better idea could be to limit the rate at which the update function is called - usually by a timer with some sensible interval.
  • If an animation is triggered only by one property and that property is unlikely to change often, remove the prop / animation from the update loop and use a listener instead. The listener may read other props as needed. I have no idea, how much overhead the listener creates so I cannot tell at which point the "does not change often" becomes invalid. I guess that every change interval > 0.5s should be considered ok to be handled by listeners. Please update this article if you have better figures.
  • I did not consider complex listeners that monitor a prop sub-tree yet. This could be interesting for animations that depend on more than one prop (still at slow change rates for all props) but this and only this props would have to be in one property sub-tree.