Board index FlightGear Development Canvas

Canvas instancing & templates

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Canvas instancing & templates

Postby Hooray » Sun Mar 09, 2014 4:49 pm

Subject: extra500 - Avidyne Entegra 9 IFD - approach
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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11427
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas instancing & templates

Postby Hooray » Sun Mar 09, 2014 5:07 pm

all important canvas classes already use "PropertyBasedElement" as the main property tree interface - this could be extended or sub-classed, to add OOP related wrappers, so that instances can apply defaults from an existing template (element/group/canvas) and override certain properties within own property tree. For example, we could have "PropertyBasedClass" which transparently handles instancing by maintaining a ref-count, and only doing a "copy-on-write" once properties really change, otherwise the "parent's" (hello Nasal!) properties are applied.

We could then even make certain properties const/readonly, and support other storage specifiers (public/protected/private) to ensure that people cannot tamper with certain things accidentally, which was also discussed on the devel list a while back, i.e. see:
http://www.mail-archive.com/flightgear- ... 37876.html
Zakalawe wrote:I think we need a bit of discussion about the architecture for this approach, especially to define a widget abstraction (maybe C++, maybe nasal) so dialog authors can't break widget functionality unintentionally


Instancing a "button widget" or "ND/PFD" would then only make certain properties accessible, while others would be const/readonly, or completely invisible/hidden, i.e. applied from the parent template "class". That way, we could even support encapsulation, and heavily reduce the Nasal space overhead involved in maintaining multiple instances of a canvas, no matter if it's a GUI widget or instrument.

The property tree already supports "setReadOnly()" methods, and additional attributes could be added to hide certain properties, or restrict their value range.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11427
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 1 guest