Canvas properties: Difference between revisions

Jump to navigation Jump to search

Canvas properties (view source)

Revision as of 18:14, 29 June 2014

1,958 bytes removed ,  29 June 2014
m
→‎Vector Data Cache: obsolete IMO
m (→‎Vector Data Cache: obsolete IMO)
Line 139: Line 139:


Also see: http://forum.flightgear.org/viewtopic.php?f=71&p=166909#p166909
Also see: http://forum.flightgear.org/viewtopic.php?f=71&p=166909#p166909
=== Vector Data Cache ===
Considering that a single cockpit/GUI may repeatedly use the same vector data over and over again, it might make sense to provide some means to cache canvas vector data in the property tree, so that we could implement a simple ref-counted scheme, and avoid unnecessary memory consumption under most circumstances:
Simple use case: Imagine a Nasal GUI loading hundreds of identical GUI widgets (buttons etc): there should only be a single copy of the "button" vector data in the canvas property tree. Here, it would make sense to load the vector data into a /cache/ subtree like /canvas/cache/data[x], and only use ALIASED properties for the data in /canvas/texture[x], referring to the original cache entry in the cache subtree (property aliasing is already supported by the SG props code).
So, whenever new vector data is written to the tree, there could be a background check to see if we already have matching data.
That would probably be simpler by using a "cache-identifier" or something like hashing. We could also use a boolean flag and provide a Nasal wrapper, which automatically activates caching. The SVG parser should be easy to extend to support a property-tree cache.
The cached subtree would be aliased and the geometry "readonly" by default (because it is shared by other canvases)
Only if the aliased subtree is modified, should we use a lazy "copy on write" scheme, so that the canvas texture gets its own copy for modification.
So even if someone goes crazy by adding lots of vector data to the property tree, it would be handled via the cache.
Caching could be explicitly enabled/disabled via a property, maybe even customized via limits (min-vector-size, max-vector-size), to ensure that it is used properly.
To see how this is handled in ARINC661, check out [http://sourceforge.net/projects/j661/forums/forum/1223353/topic/5507363].
Also, see:
* http://forum.flightgear.org/viewtopic.php?f=71&t=21090
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/73531"

Navigation menu