Space ShuttleThorsten wrote:I suppose in terms of raw information content (with sometimes close to 100 properties displayed) the DPS screens are sort of record-breaking (but then again, no one today would design interfaces that way any more).
[...]
I start being concerned about the performance impact of 100+ getprop() statements per display update...
(I suppose once we support more displays, we have to run them asynchonously to avoid peak loads during the update frames.)
For the time being, it would be better not to use/update Canvas asynchronously, the underlying property tree APIs are not threadsafe - while getprop() is a read-only operation, there is no locking taking place. It would be better to extend the Canvas system to directly support a new "property mode" using sprintf-style format strings that are assembled/updated in C++ space, i.e. without any Nasal overhead, which would benefit other efforts, too - including the PFD/ND efforts, re-implementing HUD/2D panels on top of Canvas, but even pui2canvas
I have posted a follow up here:
viewtopic.php?f=71&p=266721#p266721(what you describe, should be possible to do, but using native C++ code, without going through Nasal space, seems preferable overall)
Depending on how much progress Stuart is making with HLA/RTI, another option might be having a private property tree NODE (instance) for the Canvas system, or even each Canvas - which would make it possible to update things using a dedicated thread, including even Nasal threads.