20,741
edits
FG1000: Difference between revisions
Jump to navigation
Jump to search
→Performance
No edit summary |
|||
| Line 101: | Line 101: | ||
== Challenges == | == Challenges == | ||
=== Performance === | === Performance === | ||
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. <ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35926343/ | |||
|title = <nowiki> Re: [Flightgear-devel] RFD: FlightGear and the changing state of | |||
air navigation </nowiki> | |||
|author = <nowiki> Thorsten Renk </nowiki> | |||
|date = Jul 4th, 2017 | |||
|added = Jul 4th, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.<ref>{{cite web | it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.<ref>{{cite web | ||
| Line 121: | Line 131: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
=== Route Manager === | === Route Manager === | ||