20,741
edits
Canvas news: Difference between revisions
Jump to navigation
Jump to search
m
→2017
m (→2017) |
|||
| Line 6: | Line 6: | ||
== 2017 == | == 2017 == | ||
=== Property I/O === | |||
As a first step towards developing a G1000, Stuart Buchanan has been looking at Nasal property read/write performance, as he understands that this is a bottleneck for developing complex Canvas applications.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35974946/ | |||
|title = <nowiki> [Flightgear-devel] Nasal property lookup performance </nowiki> | |||
|author = <nowiki> Stuart Buchanan </nowiki> | |||
|date = Jul 31st, 2017 | |||
|added = Jul 31st, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
For well-organized code (aka writing only when needed, organizing the displays in suitable groups, staggered updates...), it's going to be fast enough. For a straightforward approach to complicated displays probably not. A thousand properties sounds a lot, but every update in translation is already 2 properties, combined with a visible flag and color information you're down to 166 elements you can update already. If each of them is driven by reading a value from the tree you're losing even more. Generally, if there is a way of making either method faster, it would affect performance in a positive way all over Nasal scripting because currently property I/O is in my view the largest bottleneck (especially of canvas).<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35975339/ | |||
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki> | |||
|author = <nowiki> Thorsten Renk </nowiki> | |||
|date = Aug 1st, 2017 | |||
|added = Aug 1st, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
low-hanging fruit in the canvas API: | |||
* add more calls like updateText (updateTranslation, updateRotation,...) which check whether the property to be written has changed at all against a Nasal record before actually doing property I/O | |||
* make the updateXXX methods store the node reference and use that rather than construct it afresh | |||
If the test suite numbers hold up in reality, this ought to give a factor 2 to <few hundred> (dependent on how often the argument actually has to be written - at least Thorsten was able to write 50 million numbers into a Nasal array much faster than 50.000 numbers into properties).<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35976562/ | |||
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki> | |||
|author = <nowiki> Thorsten Renk </nowiki> | |||
|date = Aug 1st, 2017 | |||
|added = Aug 1st, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
it’s easy for to add native helpers to Canvas to set some properties from code directly, rather than using the canvas.nas wrappers which then use props.nas internally. This could bypass a whole ton of Nasal if that’s the issue. Of course this code will still have to update properties from C++, so we should rather do the analysis first to see where the slowness occurs, since this could either be a very big win, or completely pointless based on that measurement.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/35976398/ | |||
|title = <nowiki> Re: [Flightgear-devel] Nasal property lookup performance </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Aug 1st, 2017 | |||
|added = Aug 1st, 2017 | |||
|script_version = 0.40 | |||
}}</ref> | |||
=== Moving map/RNAV discussion === | === Moving map/RNAV discussion === | ||
{{See also|Complex Canvas Avionics}} | {{See also|Complex Canvas Avionics}} | ||