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