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.