It isn't just the PFD and MFD showing artificial horizon, speed,
altitude, climbspeed, engine datas, electrical, fuel, navigational data
like VOR/ ILS/ GPS and much more.
The modern avionics also offers 3d-images of the surrounding terrain,
TCAS, further maps like airport diagrams, airspaces, approach plates -
all with search functions!; information about weather in real time by
satelite, autopilot, transponder, COM/NAV, audio panel and much more....
It is amazing!
You're unfortunately missing the point I've been trying to make. The
Shuttle has ~50 avionics pages implemented which you can bring on screen,
doing all sorts of things from showing temperature readings to orbital
rendezvous targeting - but I didn't multiply my numbers by 50.
I didn't, because for performance that's irrelevant, there could be 500
pages and it wouldn't hit performance more - you don't pay for the 49
pages you do not see on an MDU, you pay only for the one that is currently
displayed (unless your code is badly structured).
Now, the Shuttle avionics is staggeringly stupidly designed in displaying
a thousand parameters _at once_. It's not done like that any more,
information is reduced to the essentials in modern avionics, screens are
no longer crammed with small alphanumerics.
So everything else equal your GA display problem is going to be a factor
10 smaller than mine because you have only one display and not 11, and
it's going to be another factor 3-5 smaller because you don't try to
display 100 parameters at once but just 20-30.
Which is to say, if I can do a 1000 unique parameters per update cycle,
you ought to be able to display a GPS much faster if you code it the same
Also note that if you display 30 unique items on your display at any given
time, you don't actually need to pay update cost for 30 of them but only
for those which change in the current frame. I've started to extend the
canvas API to support this for text, but it also can be done for other
elements. Also, property I/O can much be accelerated by using setprop()
rather than props.nas as canvas does (the code just gets ugly then...)
Canvas is more than some happy little SVG-objects, which must be drawn-
those happy little drawn SVG-Objects must be driven somehow, and that's
done by nasal. And those fancy nasal-scripts must simulate or use
properties, so that we get those features mentioned above - and all this
Again, apart from the first sentence, that's a red herring. I can run
_much_ more demanding Nasal scripts involving thousands of trigonometry
operations per frame (numerical orbit fast-forwarding for instance)
without a performance hit - because running Nasal is cheap
performance-wise. Only things like property I/O or terrain queries are not.
So yes, you need to drive the SVG elements (I wouldn't draw them by hand,
I would do it procedurally wherever possible) and the I/O cost of driving
them if you have structured your code well is pretty much the number of
unique parameters you display and change in the current update cycle.
Which in my case is unfortunately ~1000, and in your case is likely ~20-50.
The fact that there are people code canvas like there's no tomorrow and
update 10 elements where an update of the group position would do the
trick at a fraction of the cost doesn't mean that canvas or Nasal are slow
- it means inefficient code is slow, and that's just as true for C++.
Nasal as such is fast, and compared with the cost of rendering the
terrain, rendering a canvas display is fast on the GPU (you can test by
rendering but not updating a canvas display), and unless you're doing
something very inefficient, calculating a display but not writing it to
the property tree is fast (you can test this by disabling the write
It's the property I/O which you need to structure well, and then canvas
will run fast. And of course the complexity of your underlying simulation
costs - if you run a thermal model underneath to get real temperature
reading, it costs more than inventing the numbers. But that has nothing to
do with canvas.