20,741
edits
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> |