Thorsten 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.)
We were recently talking about that, too - i.e. re-publishing some behind-the scenes exchanges:
Hooray wrote:I was going to take another look at the pui2canvas parser, as well as supporting the "peformance monitor" (dynamic vis Nasal/dialog-show/update) and port/integrate that with the reset/re-init Canvas dialog below:
I don't know if you have ever tried using the built-in google perftools profiler in conjunction with the recent GUI work, but the performance monitor using PUI and Nasal is already a very real bottleneck, and it remains a bottleneck even when using Canvas, because certain things are not possible/efficient, when using Nasal.
Under the hood, it is all about updating properties and updating a label/text element accordingly, we could dramaticaly reduce the degree of Nasal overhead by allowing text to be specified using printf-style format strings that get their values from a sub-branch in the element's tree (one node for each %s, %d) - that way, the whole thing could be processed in C++ space, and we would not need to use any Nasal for updating/building strings.
If this could be supported, we could also provide two modes: polling and on-update, to ensure that there is no unnecessary C++ overhead.
Complex dialogs with lots of dynamic labels could then be re-implemented much more easily, without having to register 5-10 callbacks per metrics (or timers/listeners), even though a timer-based update mode may also be useful for the C++ change.
Note that this would also be useful for the PUI parser itself, because that already supports values that may be provided by a property using printf-style formatting, there, it is limited to a single fomat string - with Canvas, we could support an arbitrary number of sub-nodes that are updated as needed.
Ultimately, that would also help with HUD/2D panels stuff, because taking values from properties and updating them using sprintf-style code is extremely common there, too - and we could avoid tons of Nasal overhead like that.
(no response needed/expected - consider this just feedback for now, based on profiling/coding experiments)