basically, 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.
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):
http://wiki.flightgear.org/FGCanvasIf, and how, you'd want to proceed from here, depends mainly on whether you are able to build from source or not.
The two wiki articles I posted, contain a few pointers. But 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
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:
http://wiki.flightgear.org/Slaving_for_Dummieshttp://wiki.flightgear.org/Property_Tre ... ol_SlavingThe steps to make subsystems optional, to exclude them, are not really difficult - for a recent thread, see:
viewtopic.php?f=71&t=23499To 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.