Board index FlightGear Development Canvas

Symbol Instantiation

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.

Symbol Instantiation

Postby Hooray » Thu Sep 27, 2012 10:00 pm

zakalawe wrote in Tue Sep 25, 2012 10:26 am:
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.


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.
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: 11959
Joined: Tue Mar 25, 2008 8:40 am

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests