| The FlightGear forum has a
subforum related to: Canvas
See $FLIGHTGEAR_SRC/utils/fgqcanvas/README.md for instructions on how to use FGQCanvas.
James has spent some of his time since FSWeekend 2016 figuring out how he might drive some ‘real’ CDU hardware from the in-aircraft CDU options, and went for a slightly ambitious approach: he's written an analogue of FGPanel for the canvas.
Analogue is actually not quite correct - unlike FGpanel this connects at the view level (canvas properties), it doesn’t run the canvas ‘model’ locally, since that would be very tough (Nasal + whole property tree needed).
This distinction was unimportant for the canvas up until now, but it’s going to become important he expects. This was prompted by his intention to buy something like this: http://www.flightdecksolutions.com/components/b737ng/b737ng-mipmain/fds-b737ng-pro-mx-cdu-color-vga/ Which means James needs the CDU screen running on its own screen/device nicely.
And he already wrote a page-based Canvas CDU over a year ago, it’s just sitting on Gijs’ hard-drive awaiting being merged.
This is currently proof-of-concept quality, but already works quite nicely:
- uses a websocket to send an entire property sub-tree (a canvas, but in principle could be anything) to another process / machine
- render the canvas at arbitrary sie/resolution
- it’s ten source files and very simple code
James is very happy with this approach so far, since any Canvas display can be trivially run out-of-process, remotely on an Android tablet, Raspberry Pi, iPhone or whatever. (he is hoping to make an app available on the Play store and App store, but one thing at a time). The 777 ND and lower EICAS pages work and look great at larger sizes. James also investigated using a binary protocol for doing the mirroring, current one is an optimised JSON protocol but swapping in a binary protocol is very doable in the future.
This has prompted James to look at some more fundamental pieces of the Canvas, because there are some things the Canvas / Map layer do which are not very performance-friendly, especially the symbol-caching / texture-atlasing can be managed better on the rendering-client side. (Plus all the overhead that comes from doing lots of work in Nasal) The system would benefit from some knowledge about screen-space pixel size, so that each per-frame change in heading / aircraft position does not cause every symbol and route-path element to be recomputed in cartesian space and then re-transmitted over the mirror-socket. (But, even doing that, and with a software rendering, it’s still fast - computers are really quick….)