FGCanvas

This article describes content/features that may not yet be available in the latest stable version of FlightGear (2020.3). You may need to install some extra components, use the latest development (Git) version or even rebuild FlightGear from source, possibly from a custom topic branch using special build settings: . This feature is scheduled for FlightGear 4.x. If you'd like to learn more about getting your own ideas into FlightGear, check out Implementing new features for FlightGear.

Note  As of 07/2014, this is being worked on via Initializing Nasal early - there are still some issues that need to be solved first, specifically related to making most subsystems optional and fully runtime-configurable using listeners and "property signals" so that SGSubsystems can be dynamically allocated - see Howto:Reset/re-init Troubleshooting and FlightGear Run Levels for further details.

See also Read canvas image by HTTP.

if we wanted to build a tablet-based emulator ourselves, we could at least join forces with the FSX and X-Plane communities to do it to grow up the pool of talent.

Should there maybe be a separate project to build an embeddable GPS navigator with different faces/UIs (and a default standalone front end)? As others have mentioned, a lot of the backend logic is the same, like doing a gradual transition from RNAV to Localiser on intercept to avoid a sudden jolt in the A/P, or calculating a turn past a fly-by waypoint. Again, that would be a way to join forces with other Sim dev communities.

Standalone Canvas Applications (MFD, instruments etc)

Started in	07/2014
Contributor(s)	various
Status	experimental/prototyping

note that the whole fgcanvas idea is primarily about taking some sort of existing MFD (e.g. PFD or ND) and render it in a fullscreen view using a dialog, e.g. along the lines of the following screenshot:

At that point, you'd obviously have to be running additional fgfs instances (with unneeded stuff disabled), and key data/properties synced with the main fgfs instance

If we want to remove an subsystem from the flight gear source code, without leaving any trace of it.. What are the essential steps ?(for example, if the sound update has to be removed, what are steps to be followed). — Divi (Aug 31st, 2015). Steps for Removing subsystems in flightgear source code. (powered by Instant-Cquotes)

i was hoping to build a program outside the FG environment — hamzaalloush (Thu Apr 02). Simgear-based subsystem with Canvas support?. (powered by Instant-Cquotes)

I am looking for a simple environment to be able to display canvas elements without starting the whole fg and wait a long long time. Does it exists ? Is there any way to do it, do you have any clue ? — Jean-Yves LEBLEU (2014-01-06). [Flightgear-devel] canvas test environment. (powered by Instant-Cquotes)

Creating a 'fgcanvas' client analogous to 'FGPanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend. — James Turner (05/2012)

If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes. — James Turner (08/2008)

So, can I run flightgear on my RPi? Under what OS are you working on the Pi? — Markus Wanner (2013-09-11). Re: [Flightgear-devel] portability of simgear. (powered by Instant-Cquotes)

more useful would be to get ARM working so we can run parts of the stack on Pis, Pandaboards and so on. This would be materially useful for various add-on functions, especially the canvas and fgcom. (I spend an increasing amount of my work time on OpenGL on ARM platforms, they have plenty of power to run graphics, depending on which GPU is on the SoC) — James Turner (2013-09-09). Re: [Flightgear-devel] portability of simgear. (powered by Instant-Cquotes)

Note we can't run FG itself without major work, since these platforms only support GLES1 or GLES2, and there's many legacy areas of the renderer which would not work. — James Turner (2013-09-13). Re: [Flightgear-devel] portability of simgear. (powered by Instant-Cquotes)

In general, we still have very few Canvas-based instruments. The majority of "glass" instruments are still hard-coded, i.e. implemented in C++ space. Such instruments are also not supported by fgpanel. FGPanel really only supports classic 2D panels that are built using stacked textures. Anything more sophisticated than that (e.g. a NavDisplay) will require a hard-coded instrument, or Canvas - both of which are unsupported by fgpanel. However, we're hoping to eventually absorb fgpanel functionality back into fgfs and come up with a special startup mode for running Canvas-based instruments in a standalone "FGCanvas" window, where the majority of subsystems would simply be disabled: http://wiki.flightgear.org/FGCanvas This would then also make FGPanel obsolete, because we're hoping to unify the 2D rendering back-end using Canvas, i.e. by implementing a 2D panels parser via Nasa/Canvas. However, there are still several things that need to happen for this to become feasible - currently, it seems this is at least another 3-4 releases away (i.e. 2+ years). Obviously, this assumption is based on the manpower currently available, and people interested in helping with this. For the time being, there are 3 core developers working towards this and a number of other contributors willing to help to get this done. Realistically, we could accomplish many things already - and if someone is interested in pursuing this, we can provide a ton of pointers and also help to varying degrees. — Hooray (Sun Jun 15). Re: Instruments for homecockpit panel.. (powered by Instant-Cquotes)

it would even be possible to use built-in FG dialogs in an external window, running in a standalone process - e.g. for an instructor console, but also for a Canvas-driven TerraGear GUI. — Hooray (Mon Jul 07). Re: How can I retire from the forum?. (powered by Instant-Cquotes)

We've been talking about having a FGCanvas mode built right into the fgfs binary at some point, analogous to how FGPanel works - just as an integrated part of the main code base, while not only supporting 2D panels, but also MFD-style cockpits and even GUI elements.

Realistically, it is only feasible to support such use-cases by having a single common backend that knows how to deal with multiple windows, rendering contexts, GPUs or multiple fgfs instances.

Basically, FGCanvas is going to be just FlightGear, in a custom startup mode, to make certain features and subsystems optional, so that the runtime footprint is reduced over a conventional full fgfs instance, and computing resources freed.

While FGPanel is great, it's a separate code base, and as such needs to be maintained separately, it also isn't as flexible - and cannot be scripted or used for glass avionics, it also doesn't support any of the existing hardcoded displays - so it's stricly about 2D panels and static/property-driven transformations.

At the moment, there are a handful systems/features in FG that need to be disabled manually, and others that cannot be disabled at all. Which is why you'll currently either need a fairly powerful computer, or use a workaround.

The hope is to make OpenGC/fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone.

Screen shot showing a the performance monitor in a patched version of FlightGear 3.2 where subsystem initialization is made better configurable and increasingly optional by allowing subsystems to be explicitly disabled/enabled during startup. Decoupling internal subsystem dependencies means that we can more easily provide support for benchmarking, but also headless regression testing - and eventually, also a standalone FGCanvas startup mode.

Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:

• flight (FDM, no problem)
• scenery (tile manager: no problem, ephemeris)
• view manager (needs restructuring)
• lighting (needs restructuring)
• terrasync (no problem)

Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas). Also see Initializing Nasal early.

checking how difficult it would be to put all aircraft related subsystems (fdm, replay, history, controls etc) into a single SGSubsystemGroup named "main-aircraft" to easily make the whole shebang optional using a single --prop for "FGCanvas" use, but also to check if it's feasible to prepare things for later reuse by the AI traffic system (for AI traffic that uses actual FDMs, APs and RMs - but also so that things are affected by the environment) , and it's actually working - even though reset/re-init is obviously hard-coded currently, which I am breaking by shuffling around subsystems, but as long as each SGSubsystemGroup implements the full SGSubsystem interface (postinit, reinit, shutdown etc), this could help clean up fg_init.cxx quite considerably [1]

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

what we're calling "FGCanvas" will be FlightGear minus a number of subsystems - i.e. a subset of FlightGear. But you will start FlightGear twice: once in "FlightGear mode" and once in a subset of it, which we call "FGCanvas" - the 2nd instance can also be running on a different computer/network obviously. It's been shown that roughly ~60-70% of the subsystems in FlightGear would not be required for FGCanvas - so, those would be explicitly disabled for the FGCanvas mode. Which also means that the hardware requirements will be much lower. Basically, you can imagine it like 1) osg, 2) canvas and 3) Nasal - even though there are a handful of additional dependencies required. But otherwise, that's basically what FGCanvas is all about. — Hooray (Mon Jul 21). Re: Need to Create a Standalone PFD. (powered by Instant-Cquotes)

Which means that you can run Nasal, but also I/O protocols - because all the FlightGear infrastructure would be -optionally- available. Performance in "FGCanvas mode" is pretty remarkable, too (see the frame spacing/frame rate counters): FGCanvas — Hooray (Mon Jul 21). Re: Need to Create a Standalone PFD. (powered by Instant-Cquotes)

basically it's a 3-step process: making unneeded subsystems optional, and rebuilding FlightGear adding an I/O protocol that syncs PFD properties (altitude, position, velocities etc) with the "FGCanvas" instance generalizing the existing PFD code accordingly to come up with a PFD framework — Hooray (Mon Jul 21). Re: Need to Create a Standalone PFD. (powered by Instant-Cquotes)

The I/O protocol part can be greatly simplified by simply using FlightGear's support for multi-instance slaving, i.e. you'd basically disable the FDM/controls part on the FGCanvas side of things, and simply use those values from the FG side: Slaving_for_Dummies Property_Tree/Native_Protocol_Slaving The steps to make subsystems optional, to exclude them, are not really difficult - for a recent thread, see: [3] To get this going quickly, you can just comment out unneeded stuff (e.g. sound, fdm/flight etc). Even though a more proper solution would be using properties to exclude subsystems optionally. — Hooray (Mon Jul 21). Re: Need to Create a Standalone PFD. (powered by Instant-Cquotes)

Discussions

I'm now in a need to create a Standalone Primary Flight Display with following requirements 1) Should be able to listen to Socket in which Flight Parameters like Pitch, Roll, Altitude etc(published by another system) are available. 2) Use the parameters to show a 2D Graphics of Primary Flight Display with Artificial Horizon, Pitch Ladder, Bank Angle indicator etc.. Is it possible for me to develop such Standalone PFD using Canvas Framework?? If not which will be a good platform to do the same. It should run in Linux Operating system. — deena102 (Fri Jul 18). Need to Create a Standalone PFD. (powered by Instant-Cquotes)

I have seen close to 10 different separate "standalone" instrument viewers implemented in various more or less esoteric languages/toolkits, including Perl, Python, Java, Ruby. Frankly, I do not believe in building even more - especially not using a proprietary toolkit — Hooray (Mon Jul 15). Re: How do I make a 2D . (powered by Instant-Cquotes)

hard-coded instruments like the existing PFD/ND stuff cannot be easily set up to support multi-instance setups. Aircraft using canvas-based instruments can be more easily prepared to support such use-cases, but may still require a few C++ tweaks. This is something that we're hoping to support sooner or later, probably by supporting an osgviewer viewer for multiple windows, but also by allow canvases to be referenced/driven by different fgfs instances eventually. For the time being, the necessary steps are unfortunately aircraft specific, because existing solutions are not particularly consistent, but rather fragile still. This is likely to change during the next 2-3 release cycles, because we're also hoping to support a standalone canvas startup mode, that would allow any canvas-based instrument to be rendered and slaved to another instance. — Hooray (Sat Apr 05). Re: Displaying Cockpit Instrument display on multiple screen. (powered by Instant-Cquotes)

you will almost certainly want to forget the "old" texture-based approach and directly use the canvas system instead, while there are not as many examples, it is easy to get started - especially if you should already have some scripting experience (JavaScript/HTML5). I suggest to check out the development/canvas sub forum and ask your questions there, you may also find a bunch of questions already being answered by browsing the canvas sub forum. The canvas allows you to use SVG images drawn with Inkscape, and easily use raster images and custom drawing commands using OpenVG paths. However, please do note that the canvas cannot currently be run in a standalone/FGPanel-fashion - there's been some talk about that, but that will at least take another 1-2 releases in my opinion. That being said, you could certainly come up with a canvas instrument panel, and then simply use in a dedicated fgfs instance, which is slaved to a corresonding master instance. — Hooray (Sat Jul 13). Re: How do I make a 2D PFD with pages. (powered by Instant-Cquotes)

I'd suggest to use our built-in Canvas system in combination with Nasal scripting, we already have a standalone "FGPanel" client that renders instruments in a separate program, for distributed multi-machine master/slave setups: http://wiki.flightgear.org/FGPanel By using a Nasal/Canvas-based framework, you can also easily reuse existing instruments/textures available in FlightGear (ADF, RMI, HSI etc), including various 2D instruments - it's just a matter of some scripting. And there's already been talk about eventually also supporting this for canvas-based avionics: http://wiki.flightgear.org/FGCanvas Note that FGPanel is fairly limited feature-wise, it doesn't support any of the hard-coded displays (TCAS, AGRADAR, WXRADAR, NavDisplay) or other owner-drawn gauges, it's stricly for static textures animated through properties. — Hooray (Mon Jul 15). Re: How to access navigation data in FlightGear ?. (powered by Instant-Cquotes)

Ultimately, the best solution would probably be to have Canvas/ FGpanel running natively in ARM architectures so that they can be used in Android Tablets. I have my doubts regarding the addition of screens to Raspberry PI, Blackbone, Panda, etc. A 10.1" HDMI screen costs around UDS 145 (http://www.adafruit.com/products/1287), which is almost the same price as a cheap tablet. On the other hand, the Raspberry PIs are the best for hacking the hardware needed to make instruments. Here is some paralell work I am doing with my Raspberry PI: https://www.youtube.com/watch?v=DdqbhyOJx-E https://www.youtube.com/watch?v=DxtqKIT068w — saul (Thu Jul 31). Re: Flightgear Android Primary Flight Displays for Airliners. (powered by Instant-Cquotes)

you should be aware of glass cockpit related efforts, especially Canvas - most airliners & jets will sooner or later benefit from being ported to Canvas, e.g. to use Gijs' NavDisplay framework, or at least Philosopher's MapStructure framework for mapping purposes. Thus, if this is also about the actual display itself, people should be aware of related canvas efforts, especially FGCanvas: http://wiki.flightgear.org/FGCanvas I am involved in both, the NavDisplay and MapStructure efforts, and my mid-term plan involves supporting a standalone mode for all Canvas-based glass instruments, including the ND, but also other instruments like the PFD, EICAS, CDU or EFB. This may sound like a lot of work, but it's mainlyy a matter of introducing a a few helper classes and ensuring that people actually adopt and use those. In the long-term, I really want to support distributed FlightGear setups like those at FSWeekend/LinuxTag, where multiple computers may be used to run a single simulator session - including properly synchronized glass instruments like the PFD/ND etc. This would also help improve the multiplayer experience, especially dual-pilot setups etc. — Hooray (Sat Jun 07). Re: computer2cockpit. (powered by Instant-Cquotes)

There's also the long-term plan to eventually port FGPanel back into FG and come up with some sort of "FGCanvas" mode, where Canvas-based displays could be run in a separate "standalone" mode and interface to the main/master FG instance. I don't think that the Canvas system currently builds against just OpenGL ES - but it should be possible to identify problematic use-cases and make the Canvas support OpenGL ES by setting some OSG traits accordingly - at some point, i.e. 12+ months from now In general, it pays off to unify things - otherwise, there's lots of duplication and re-invention involved. Technically, we could definitely run an OpenGL ES-based Canvas on a mobile device, we just need people interested in pursuing this and playing with it - as well as report any issues/showstoppers Such an integrated solution would also make it possible to show any canvas texture (instrument, dialog/window, MFD etc) on external devices: http://wiki.flightgear.org/FGCanvas — Hooray (Tue Jan 28). Canvas & OpenGL ES (Rasberry PI, Android etc). (powered by Instant-Cquotes)

it would make sense to coordinate such efforts, because the requirements will be very similar. Even some core developers discussed this on the devel list: http://wiki.flightgear.org/Howto:Optimi ... .2F2013.29 For example, see: http://wiki.flightgear.org/Howto:Optimi ... le_devices The Canvas is a property tree-based subsystem using listeners, the canvas is primarily a wrapper on top of Shiva and OSG that is invoked via listeners. So all the OpenGL code is either located in Shiva or in OSG - OSG can be told to use OpenGL ES. So it would be a matter of experimenting with it. For this particular project, I would suggest to extract the Canvas into a standalone executable - something like this has been previously done by TorstenD when he came up with FGPanel, he "just" extracted FlightGear's 2D panel code and turned it into a standalone binary. This alone would help us ensure that we can optimize the canvas to support OpenGL ES - once that is working, you could cross-compile the standalone canvas binary. Technically, this will involve some -but not all- of the steps outlined at: http://wiki.flightgear.org/FGCanvas (not all of them, because FGCanvas is eventually intended to be merged back into the main code base) — Hooray (Fri Jan 31). Re: TQ/Panel for FG made with Kivy. (powered by Instant-Cquotes)

This should give you a rough idea on what's involved in extracting the canvas system into a separate code base, to cross-compile it for other devices. Basically, the steps are: use the FGPanel/FGRadar or SGApplication code base to come up with a SGSubsystem-based program add the Nasal, events (timers) and property tree subsystems add the canvas system check where OpenGL ES is not yet supported, report issues or fix them directly come up with workarounds regarding the FBO issue 40-60% of this are already done inside FGPanel and FGRadar - so the first weekend will be primarily spent doing "copy & paste". If you are interested in working on this, you should obviously know some C++ and you should be able to build from source. If that's not a problem, I suggest to raise the question in the canvas forum, so that TheTom can provide some more informed input. It would definitely be a useful project, not just for Rasberry PI support, but for FG itself - because the whole FGPanel/FGCanvas idea is generally agreed to be useful, so any work related to this would be highly appreciated, and we're here to help you accordingly. — Hooray (Fri Jan 31). Re: TQ/Panel for FG made with Kivy. (powered by Instant-Cquotes)

I have this cray idea floating around in the back of my head for quite some time. As a long time RC airplane enthusiast, wouldn't it be cool to embed a small display + raspberry pi in the cockpit of a scale model airplane? Wouldn't it be cool if your model airplane had a live, working cockpit display? If you are wondering where I'd get the data to drive the cockpit display, that would come out of the UAV side of my life. The sensor I/O and fusion is already solved. http://gallinazo.flightgear.org/uas/flight-milestones/ — Curtis Olson (Jan 10th, 2016). Re: [Flightgear-devel] FGPanel on the Raspberry Pi. (powered by Instant-Cquotes)

Using the Pi as an avionics platform has been on my todo list for a while - I've had a box full of parts just waiting. A 7" HDMI display with a touch screen overlay for it. — geneb (Jan 10th, 2016). Re: [Flightgear-devel] FGPanel on the Raspberry Pi. (powered by Instant-Cquotes)

I'll get a Raspberry Pi soon, so I will probably try to also run the canvas there — TheTom (Fri Jan 31). Re: Canvas & OpenGL ES (Rasberry PI, Android etc). (powered by Instant-Cquotes)

I've just seen that the Raspberry Pi has hardware accelerated OpenVG support, so we won't need ShivaVG and the path rendering should be quite efficient. — TheTom (Fri Jan 31). Re: Canvas & OpenGL ES (Rasberry PI, Android etc). (powered by Instant-Cquotes)

Right, not only is OpenVG natively supported in hardware, but there's even a vector font library available named "vgfont". This OSG discussion may also be of interest for anybody pursuing this venture: http://forum.openscenegraph.org/viewtop ... &view=next And specifically: https://code.google.com/p/osgrpi/ — Hooray (Fri Jan 31). Re: Canvas & OpenGL ES (Rasberry PI, Android etc). (powered by Instant-Cquotes)

FlightGear's canvas instruments are completely different from HTML5/Canvas, FlightGear's Canvas uses OpenGL/OSG and provides full hardware acceleration - so there's really no direct advantage when it comes to reusing FG's canvas instruments in some form of browser-based cockpit view. Your best bet still is FGPanel or the FGCanvas effort (which is really just going to be FG in a down-stripped runtime mode, nothing more). To render glass cockpits in some separate program, you would need to use the canvas system available in SimGear - which is exactly what the FGCanvas idea is all about, just as part of the main fgfs code base. However, you could create a PFD or ND in a browser using HTML5/Canvas - you would just need very little data out of FG, so there's no problem here - but you would basically be recreating things, there's no sane way to reuse existing FG resources here. So, as someone familiar with most recent glass cockpit developments using the Canvas, I would suggest to either abandon the idea of using FG/Canvas instruments, or look into required changes for supporting FGCanvas, analogous to FGPanel. But ultimately, that still means that you'll need OpenGL to run things. Otherwise, you would need to create a PFD/ND from scratch using just JavaScript and HTML5 and use FlightGear to provide the required data - definitely do-able, not even difficult, but kinda redundant obviously. On the other hand, being able to render glass cockpit stuff in a browser would indeed be kinda cool. — Hooray (Sat Dec 21). Re: Virtual Panel/Control from Web Browser. (powered by Instant-Cquotes)

FGCanvas (standalone canvas rendering analogous to fgpanel)

Objective: Brainstorming of all ideas related to fgpanel-related (standalone) functionality for the new Canvas subsystem

• Torsten: "fgpanel is the 2d-panel code from flightgear wrapped into a simple standalone application being able to display 2d instruments on very simple hardware with basic OpenGL support. Find the sources dropped here: https://gitorious.org/flightgear-pmpt/panel?p=flightgear-pmpt:panel.git;a=summary " [4]
• James: " I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people)" [5]
• Hooray: "the standalone 2D panel is actually a great idea, and if this could be improved on, this could make other solutions (like openGC) obsolete. I think that's important because there are so many similar projects. maybe there is a way to use FG itself in a special "mode" for just rendering 2D instruments, getting the properties for each instrument from a master fgfs instance.Such a new "instrument only"-mode could then run with most subsystems disabled (like i.e. sound, fdm, weather, scenery, terrain etc) and only render FG XML instruments. The corresponding properties could then be retrieved from the fgfs main instance, probably using a custom protocol. So I really like the idea of having a standalone mode, but I am not sure if it should be a completely separate code base (sounds like maintenance hell to me actually). Instead, it would probably make sense to make some more subsystems optional so that they can be disabled on demand, then the same fgfs binary could be used for starting up in an "instrument only" mode that only renders 2D instruments with properties being read from a master instance." [6]
• James: "That's more or less exactly what it will be - and yes, it will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. " [7]
• Hooray: "At some point looking again into cigi might actually be interesting to handle fgfs<->fgpanel communications, as you may remember, cigi was first brought up some time ago in the DIS/HLA thread and would seem like a perfect match in this context, it's all open source (GPL in fact) and an established standard used by many major players in the aviation industry:" [8]
• James: "Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend." [9]
• Hooray: "Regarding Torsten's fgpanel work, it would be good to eventually generalize this in such a fashion, that "canvas" instruments could also be rendered standalone at some point."
• Hooray: "Unfortunately, there are many hard coded assumptions in the code currently. The code OFTEN assumes that there's a an aircraft, FDM scenery, sound etc. Basically, all the stuff that won't be needed by a standalone FGCanvas/FGPanel. And the next funny thing is that all the Nasal code in $FG_ROOT/Nasal is also making lots of these implicit design assumptions (such as geodinfo() calls (depending on scenery/tile mgr) etc). Basically, this means that there will be lots of refactoring involved for a standalone canvas client, not just C++ code, but also Nasal code."
• TheTom: "Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas..."

Some more ideas have been collected here: SGModule - standalone SGSubsystems.

Also see: Howto:Creating fullscreen Canvas applications. Also see FlightGear CIGI Support (Common Image Generator Interface).

Property Synchronization between fgfs and fgcanvas

See also Emesary.

I've always wondered what would be involved in adopting HLA. Could we start using it today, i.e. for a very small proof of concept? Do we need an implementation? Who would be able to do it? What does the code already in SimGear do? A little message passing doesn't sound like a bad idea to me, if I understand it right. — Philosopher (Tue Jul 08). Re: FGCanvas Experiments & Updates. (powered by Instant-Cquotes)

I think even just preparing the SimGear code for this would make sense, the canvas system would have a simple and elegant solution for "aliased" properties with listeners - i.e. where properties may be looked up using different criteria (by-index, by-name).

And for the whole FGPanel/FGCanvas idea, this will definitely be useful - because it's all about allowing two property trees to communicate with each other.

In other words, if we had an option to link properties and "mount" them in some custom location, then it would also be easy to handle the FGCanvas idea such that it always writes to the local fgfs property tree, which is transparently forwarded to the right end point, i.e. the standalone FGCanvas instance.

Currently, in FGPanel, this is handled separately and there's no elegant design or solution at all. The network protocol must be separately set up using an XML/IO protocol file, which duplicates properties from the main instance to the "slave" instance, i.e. explicit networking I/O.

Now if we had a feature to supporting "linking" or mounting, then this could later on be extended such that custom "transport" channels can be added, i.e. IPC via sockets (e.g. some simple form of reliable UDP using the multiplayer code in FG for the basic property primitives like int, float, double, string)- for FGCanvas that would mean, that all Nasal modules would only ever write to their local property tree instance, and that they don't need to be aware of the differences or the transport technique used.

I think the Nasal code could be really kept simple like this, because there would never be a different between a "local" or a "remote" FGCanvas instrument - so no explicit maintenance required.

Probably, the existing aliasing code could be extended to support this: https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/props/props.cxx#l774

Would something like this work for your C130J EICAS or MCDU work, I mean such that all the communications details are handled transparently by a network-enabled property tree with "link/mount" support, so that it would be trivial to run an instrument separately, in a different process - on a different computer, just by writing to a mounted remote property tree?

Referring to Remote Properties and the mentioned "mounting" support:

For displaying one would just need to mount the canvas branch inside the remote EICAS FlightGear instance. If also interaction back to the main FG instance is needed it would also be needed to write to a remote tree. This can be handled the same if remote mounting also supports writing in all directions. So, yes with fill mounting support this would be possible

One would just have to decide on which instance of FG the calculations of the ECIAS and other displays should take place, but with full mounting support this should be easily distributable as computing power is available.

Yes, that's true ... on the other hand, even if we should be able to run the Canvas system standalone via FGCanvas one day, it would still just be a "display" - i.e. full scripting support would be in a different league, because it would require an embedded Nasal interpreter. So many scripted calculations would initially take place in the main fgfs process, and FGCanvas would "just" display the results via some form of mounted "remote property tree", so that the main fgfs process just writes to a certain location which is transparenly sync'ed/mirrored to another "slave" fgfs process, where the canvas would be rendered.

You are right that the computing power would be available - but obviously there's a certain overhead, i.e. for property replication, so this would require some form of "ratio metric" - i.e. average amount of properties synced per second, vs. time spent drawing/updating the display. So that we can know if we are limited by the throughput or by the computing power

By default, I would expect that the various canvas Nasal wrappers just write to the main fgfs property tree directly, which is then transparently forwarded to another process - so everything in scripting space, would still be calculated in the fgfs main loop, while all canvas-related computations triggered via listeners, would then be "distributed", i.e. run in the "delegate" process - because that's where the callbacks would be invoked.

A while ago, I played around with showing canvas instruments in a slaved fgfs instance - and it actually worked pretty well just by using the existing telnet interface, the subscribe command and 20 lines of Nasal to fix up property path index numbers, while the telnet protocol isn't very fast - it was sufficient to show the airport selection map in a slave instance, as a cockpit texture - without any C++ changes. We once had a long discussion about necessary changes to "mount" remote property trees in a local property tree to replicate state - but the experiment showed that even a crude synchronization mechanism like the props protocol works well-enough for a single instrument.

In summary, we really need to make sure that whatever form of caching/optimizations are introduced, that they can work in master/slave setups, and that is automatically the case as long as the property tree is the sole storage and transport mechanism, so if there is some form of cache, it needs to be local and transparent to the property tree - so that slaved instances get their chance to update their local cache, rather than cross-referencing cached items in multiple interlinked instances.

While it may not seem important right now, because most other simulator features are similarly broken or "crippled", the canvas system is the most feasible chance to address these once and for all.

References

References