Canvas MFD framework: Difference between revisions

Jump to navigation Jump to search

Canvas MFD framework (view source)

Revision as of 17:00, 2 February 2014

7,037 bytes removed ,  2 February 2014
m
http://forum.flightgear.org/viewtopic.php?f=71&t=21840&p=198380#p198206
m (http://forum.flightgear.org/viewtopic.php?f=71&t=21840&p=198380#p198206)
Line 1: Line 1:
{{infobox subsystem
|image =777-display-selector.png
|name =Canvas MFD Framework
|started= 02/2014
|description = MFD Framework
|status = Under active development as of 02/2014
|maintainers  = F-JYL, 5H1N0B1, Hooray
|developers = F-JYL (since 02/2014),
<!--
|folders = [http://gitorious.org/fg/flightgear/trees/next/src/Canvas $FG_SRC/Canvas]
          [http://gitorious.org/fg/simgear/trees/next/simgear/canvas $SG_SRC/simgear/canvas]
|topic-fgdata= (main repository, master branch; https://gitorious.org/~tomprogs/fg/toms-fgdata/commits/canvas-gui-demo)
-->
|subforum= http://forum.flightgear.org/viewforum.php?f=71
}}


{{Stub}}
{{Template:Canvas Navigation}}
== Background ==
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. 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.
A common framework in the background (with some common elements like "rotating" numbers, HSI logic, trend vector calculations, etc.) is definitely a good idea.
Canvas MFD displays are just canvas textures, which are just represented as "properties", or rather, "property branches" - in the form of /canvas/by-index/texture[x] - you can use the property tree browser to check how these work - but basically, each canvas texture can have multiple "placements", such as "aircraft", "scenery" or GUI (dialog/window) - these placements maintain a reference count internally.
Toggling between different image sources is also accomplished by supporting recursion through "nested canvases" - i.e. a canvas can "include" (reference) another canvas and use it as the image source (raster image).
Thus, technically, the only thing involved would be coming up with two classes for "displays" and "image generators" - where each would be internally mapped to a canvas texture, the image generator would be "black box" where rendering takes place - while the "display" would be just a simple canvas that references the proper canvas texture, based on the currently selected switch/mode.
Meanwhile, I would prefer coming up with a real MFD framework that manages different displays/screens and image sources.
That should then also help with PFD/ND/CDU and EICAS/EFIS stuff.
Philosopher's MapStructure framework has been specifically designed to support the notion of controllers for these things, so need to add any heavy hacks to the code - we should better work together and ensure that MapStructure ends up in fgdata soon enough ...
Gijs already started working on a MFD creation framework for the 744, and as previously mentioned, certain features are going to be identical - regardless of aircraft, i.e. bizjet, boeing, airbus etc - most MFDs will have knobs to adjust brightness or change video sources - so I'd rather keep the general design in mind here, and not implement such things specifically for a certain aircraft. Ultimately, it really just boils down to mapping a few properties to the corresponding canvas properties.
{{cquote|I also need a better way to switch pages on the lower EICAS. Right now I delete/re-create the Canvas with this code. It doesn't work well though; at times no page is loaded at all. Of course I cannot delete a Canvas when I have it displayed in a dialog, so this method is probably doomed...
<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=19&t=7867&hilit=switch+mfd&start=75#p191702
|title=The making of the Queen
|author=Gijs |date= Sun Oct 13, 2013 9:04 am}}</ref>|Gijs}}
{{cquote|I'm also doing some work on my C-130J cockpit and therefore have got nearly the same problems^^ There are currently five screens with a lot of pages which can be freely placed on any of the screens. I'm not yet sure on how to setup this system in detail. If displays/windows/etc. show exactly the same thing they should also use the same canvas. One approach would be to use a canvas for each page and add one ore more placements to it depending on where it should be displayed.
Another approach would be to use a canvas for each screen and either reload each page on switching or after loading once hide the according group.
A completely different approach (which probably also will require some core changes) is to allow moving groups between different canvasses and also just to a storage location to move pages around as needed.
<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=19&t=7867&hilit=switch+mfd&start=90#p191764
|title=The making of the Queen
|author=TheTom |date= Mon Oct 14, 2013 5:02 am}}</ref>|TheTom}}
{{cquote|It would probably be a good idea to look at existing airliners in FG, such as the 744, 777 and then come up with a simple Nasal-space framework to manage image sources and screens, so that a screen selector would ideally only manage placements, while supporting different MFDs for each pilot - analogous to how A661 has the concept of an image generator (IG) and a cockpit display system (CDS).
For most modern jets it would make sense to introduce some intermediate layer that wraps the main canvas system, so that different displays (PFD, ND, EICAS, M/CDU etc) can be conveniently managed.
Basically, we only need to add a handful of Nasal wrapper classes that provide the building blocks for any kind of EFIS, i.e. generic components such as:
* display (CRT/LCD)
* source selector: http://www.meriweather.com/flightdeck/747/ctr-747.html
* image source (a Nasal class that simply wraps a canvas)
* display settings (brightness etc)
cockpit developers would then ideally use existing components or add new ones as required, for different types of EFIS (777, 747, A320, A380).
PFD/ND and EICAS/ECAM or MCDUs would be built on top of these.<ref>{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=19&t=7867&hilit=switch+mfd&start=90#p191764
|title=The making of the Queen
|author=Hooray |date= Mon Oct 14, 2013 5:02 am}}</ref>|Hooray}}
<references/>
== Design ==
* Screen
* Image Source
* Switch/Selector
* Placement Manager
From am design point of view, I would probably introduce a handful of helpers to help with all these tasks:
* SGSubsystem wrapper for Nasal-based subystems
* MFDScreen (wrapper for canvases referenced as raster images)
* MFDImageGenerator (wrapper for a canvas rendering context)
* CockpitButton (Switch, Button, Selector)
* MFDSourceSelector (wrapper for assigning different image generators to a single canvas screen)
* NavDisplay (wip)
* PrimaryFlightDisplay
<syntaxhighlight lang="nasal">
# wrapper for a cockpit placement
var Screen = {
};
# wrapper for any Nasal class managing a canvas
var ImageSource = {
};
var SourceSelector = {
};
</syntaxhighlight>
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/67125"

Navigation menu