(cross-posting from the mailing-list, please reply there if you have some technical comments, but I would like feedback from aircraft developers about this)
I’ve spent some of my time since FSWeekend figuring out how I might drive some ‘real’ CDU hardware from the in-aircraft CDU options, and went for a slightly ambitious approach: I’ve 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 I expect.
This was prompted by my intention to buy something like this:
http://www.flightdecksolutions.com/comp ... color-vga/
Which means I need the CDU screen running on its own screen/device nicely. And I 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 size/resolution
- it’s ten source files and very simple code
It looks like this:
Of course, there are some issues:
- current code uses Qt+software rendering, I am improving this to use OpenGL rendering (but still Qt-based)
- there’s some artefacts from imported SVG which are more visible with my renderer than the ShivaVG based one. (As you can see in the screenshot above, the ‘tails’ on the compass rose ticks are present in the data indeed)
- I will investigate making a solution using Skia (https://skia.org) as the backend, because this would give good performance via its OpenGL backend, make people who don’t want to use Qt happier, and could also replace the OSG rendering of the Canvas within FlightGear itself, allowing us to ditch ShivaVG (which is unmaintained) and probably improve performance substantially. (Skia can do SSE3/NEON optimised software rendering in a background thread, so Canvas wouldn’t eat into our OSG / triangle budget)
(Of course there is no such thing as a free lunch, Skia is a large dependency too!)
I am 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. (I am 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. I 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 me 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 I think 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….)
Unfortunately, the 757 and 777 PFD and upper EICAS are implemented as 3D animations, not Canvas, and hence currently can’t be remoted. (I need to try the 747 and MD-11 next as more test-cases) I know Thorsten R has done lots of Canvas work for the Shuttle, but I don’t know what (if any) can be generalised? I’m imagining a library of some standard elements like tapes and digital gauges, or at least best-practice examples. Or maybe someone already has a PFD and upper EICAS done than can be modified? The 777 is very similar the 787, 744 and 737NG, and the 757 one is similar to the 737-300/400/500.
Any comments on the current canvas behaviour would be interesting. And of course please try the code once I submit it - I am sure there’s many edge cases and bugs to fix. I know there was some work on HUD-via-Canvas already, it would be great if those pieces already exist in a reusable form since HUD and PFD elements are very similar.
Similarly if people have known test-cases where current Canvas performance is a limiting factor (again I know Thorsten mentioned this in the context of the shuttle) that would be interesting, since obviously there’s no point adapting more and more things to use the Canvas if the performance sucks.