D-Leon wrote:for the extra500 PFD I'm thinking about to split the page into some layer(cached canvas).
- background all static images
- event/loop driven animations
I don't know if this make sense it will cost a lot of mem. Will try a more instrument orientated approach.
I have been thinking about this a bit, and I'd suggest not to spend too much time implementing this.
Overall, the whole issue is all about "instancing" canvas elements/groups based on defaults, i.e. using a "template" (element/group or Canvas).
We are basically already using this method to implement a simple caching scheme, where the image is identical, but we're overriding location/size.
But based on the recent MapStructure/NavDisplay and Avidyne work, I am thinking that we should discuss a more generic method here:
Simply because ultimately this all boils down to having a "template" and applying it a new element/group/canvas, while overriding certain attributes (properties).
And that's basically an common requirement that's shared with the GUI code, where styling is needed.
TheTom has already done a lot of work related to this as part of Canvas::Element.
The problem is with doing this in scripting space is at least twofold: 1) performance/overhead, 2) not being easily scalable outside a single process (think fgcanvas)
So we better stop doing this kind of stuff in Nasal space and instead look for means to generalize the C++ code, so that we can specify "templates" and properties that need to be overridden in other instances.
Kinda like an "OOP" framework implemented on top of the property tree, with "classes" (=templates) and "instances" (objects), where custom properties are overridden.
Tim Moore's effects framework is kinda doing the same thing already: implementing an object-oriented wrapper on top of the property tree, where "effects" can inherit from other effects, and override certain properties.
So we already have 2-3 instances where "property inheritance" is implemented in existing subsystems.
And rather than doing the whole thing in Nasal space, I'd prefer reusing existing C++ code for this.
Basically, a canvas-based instruments/mfd or GUI widget may have dozens of "instances", and those should NOT be managed by Nasal data structures (GC overhead, performance), but rather by the underlying C++ code.
So we really only need to look at the styling code and see how this could be adapted to support "template"-based customization, where an existing canvas element/group could be specified as the template, and certain properties would be overridden.
That should make it possible to use a lot of OSG-level optimizations.
It is kinda redundant describing a full "widget", "instrument" or MFD if there's already an existing instance, we really only need to "inherit-from" an existing canvas/element/group, maintain a refcount, and override certain properties (color/position, size, style).
And at that point, it should no longer matter if we're instancing a button/widget, or a fully "instrument" like the NavDisplay.
This could help greatly simplify the Nasal code, while also improving performance.