Re: [Flightgear-devel] RFD: FlightGear and the changing state of air navigation

[Thorsten R. <tho...@sc...>]

> 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  
way.

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 
> together costs.

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  
commands).

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.

* Thorsten