Board index FlightGear Development Canvas

Canvas::Element Instancing at the OSG level

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::Element Instancing at the OSG level

Postby Hooray » Mon Nov 23, 2015 5:09 pm

Preserving some PM discussions for the future:
Hooray wrote:Subject: How to display Airport Chart?
TheTom wrote:I will add a new element type to render symbols from a "Cache-Texture" to improve speed of canvasses showing lots of symbols like eg. the navigation display. You will basically be able to set position (maybe rotation) and index of the symbol in the cache-texture and possibly a color for each instance...


That could be helpful to speed up a few MFD use-cases:
Is that something you are still interested in ?
How were you planning to support this ?
I was thinking of exposing corresponding properties at the ::Element level and map those to osg::StateSet() calls, so that things like color could be changed on demand, while still referring to the cached texture.


http://wiki.flightgear.org/Howto:Reset/ ... leshooting
Image

http://wiki.flightgear.org/Avidyne_Entegra_R9
Image

For GUI widgets, but also MFDs, as well as 2D panels, it would be good to implement "instancing" support by mapping the corresponding OSG APIs to Canvas::Element attributes (properties), so that certain element parts can be shared, i.e. a typical dialog/MFD may have tons of identical elements (OSG scene graph elements), that could use a common osg::group and/or osg::StateSet internally, which should help significantly reduce the osg overhead.

We could mark some properties as "invariant" (static) and map OSG's support for deep/shallow cloning to helpers, so that an existing element can be used as the "template" for other/similar elements (think GUI buttons, labels, but also MFD elements).

Internally, OSG can even build a texture atlas for recurring textures to reduce unnecessry osg::StateSet changes.

We could also expose a method to "finalize" a Canvas Element, at which point its osg data variance may be changed to be STATIC instead of DYNAMIC - this could for example apply to background images and other static overlays.
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: 11968
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas::Element Instancing at the OSG level

Postby Hooray » Sat Dec 19, 2015 3:47 pm

This is one of the most common feature requests related to Canvas:

Subject: Space Shuttle
Richard wrote:I'm currently not sure if we can share the canvas elements across displays, so I've made copies of everything for each display.


Subject: Dynamic duplication of elements
Gijs wrote:Hi,

just wondering if it is possible to duplicate a SVG element in Nasal? I'd like to draw a symbol only once in the SVG and then place multiple instances of it on my display. They need to be unique elements, as I'd like to animate them independently. I've looked for "duplicate" or "copy" in the API, but didn't find anything...


Subject: Using a canvas map in the GUI
zakalawe wrote:
TheTom wrote in Mon Sep 24, 2012 8:40 pm:I'm thinking about using a separate canvas for each symbol so that every instance of it is just a textured quad. For efficiency reasons it would be good to draw all symbols to a single canvas/texture and put all quads into a single node. So probably I'll add a new element type for putting quads into a single element which are all rendered at once. Maybe we can even use a geometry shader to just copy the positions to the GPU and generate the full quads with the shader. Ideas and suggestions are always welcome :)


Hmm - that's possible. The issue there (at least based on the NavDisplay) is that there's quite high variance in the symbols, e.g. colour changes. For the ND I keep the symbols at greyscale, and colour them based on parameter data (active vs tuned vs inactive for navaids, for example)

Definitely needs some thought, but I think it can be an upgrade - we don't need to get the design right immediately! I do like the idea of the Canvas managing the symbol cache texture, however, since generating it by hand (as the TCAS and ND currently require) is annoying.



Subject: Symbol Instantiation

Hooray wrote:Parametrization of cached symbols/drawables (i.e. canvas groups) will definitely be useful - I like the idea of having generic symbols and transforming them separately. This could work like a "copy-on-write" scheme, where the unmodified canvas group data is used, and modified properties get copied for customization purposes - which would also help reduce the memory footprint. Basically, we could have a boolean flag "cached" and a "cache-id" to simplify the lookup - groups set up like this, would not be texture-specific but could be kept in the global canvas tree (i.e. under canvas/cache), where we could keep a ref-count of all symbols.

From an implementation point of view, we could re-use the "property-inheritance" code that Tom's recently been working, we've covered quite a lot of ground in that discussion, and with 2-3 little changes, this could be directly used here - because the same code will serve as the styling backend, where "copy-on-write" could just as well be used to reduce the memory footprint.

Thinking this through, it's an extremely powerful concept, because most GUI widgets will also share certain attributes/data structures.



Subject: Using a canvas map in the GUI
TheTom wrote:
zakalawe wrote in Mon Sep 24, 2012 1:13 pm:I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.


I'm thinking about using a separate canvas for each symbol so that every instance of it is just a textured quad. For efficiency reasons it would be good to draw all symbols to a single canvas/texture and put all quads into a single node. So probably I'll add a new element type for putting quads into a single element which are all rendered at once. Maybe we can even use a geometry shader to just copy the positions to the GPU and generate the full quads with the shader. Ideas and suggestions are always welcome :)

zakalawe wrote in Mon Sep 24, 2012 1:13 pm:So far I didn't see how to handle the route-path in the Canvas map, since it requires a path with both ends mapped by geo-coord.

If you use Path.setDataGeo() all coordinates are mapped.



Subject: Canvas instancing & templates
Hooray wrote: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: 11968
Joined: Tue Mar 25, 2008 8:40 am


Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests