20,741
edits
Canvas properties: Difference between revisions
Jump to navigation
Jump to search
m
→Vector Images (Status 07/2012:SVG parser implemented and available)
| Line 105: | Line 105: | ||
Now, if we had support for cascading canvases, then we could implement the Nasal base class such that it shares a single canvas base texture, and merely applies a different context of "settings" for each instrument. This would mean that even rendering 100x the same instrument with different data/settings, we would just have a single "shared" canvas texture. | Now, if we had support for cascading canvases, then we could implement the Nasal base class such that it shares a single canvas base texture, and merely applies a different context of "settings" for each instrument. This would mean that even rendering 100x the same instrument with different data/settings, we would just have a single "shared" canvas texture. | ||
=== 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. | |||
=== Vector Images (Status 07/2012:SVG parser implemented and available) === | === Vector Images (Status 07/2012:SVG parser implemented and available) === | ||