20,741
edits
Canvas MapStructure: Difference between revisions
Jump to navigation
Jump to search
m
→The SymbolCache: http://forum.flightgear.org/viewtopic.php?f=71&t=25263&p=230788#p230788
m (→The SymbolCache: http://forum.flightgear.org/viewtopic.php?f=71&t=25263&p=230788#p230788) |
|||
| Line 810: | Line 810: | ||
There are still several layers where caching+styling isn't widely used yet - however, over time this is the correct method to lighten the canvas workload quite a bit, and doesn't require any C++ level modifications. If you're seeing heavy impact on performance with complex layers, we suggest you explore adding styling and caching support as described above. | There are still several layers where caching+styling isn't widely used yet - however, over time this is the correct method to lighten the canvas workload quite a bit, and doesn't require any C++ level modifications. If you're seeing heavy impact on performance with complex layers, we suggest you explore adding styling and caching support as described above. | ||
Originally, the whole point of the cache was to simplify symbol management - meanwhile, it also supports styling. Under the hood, all it is dealing with is Canvas elements rendered to a single canvas, with each element having look-up coordinates conveniently stored in a hash. Which means that the SymbolCache could also be easily adapted to become a '''LayerCache''' at some point. | |||
This may be very useful in order not to re-draw redundant layers: for instance, the compass rose on the ND can be considered "redundant": no matter how many NDs you are displaying - it makes sense to treat the compass rose as a dedicated layer on its own (see APS.* for examples) and then render that into its own texture map - we could easily set up a LayerCache analogous to the existing SymbolCache - transformations (rotating) would then merely be applied to the referenced raster image - all of a sudden, there will be less work for shivaVG (the OpenVG rendering back-end) to do, because the compass rose will rarely -if ever- need to be updated at all. | |||
All variations will be rendered into a layer cache and the COMPASS.symbol file would merely reference the correct sub-texture (e.g. plan/arc), and merely update/rotate the raster image child referenced by the actual ND. | |||
We kinda discussed the technique a few times already - i.e. introducing the concept of an "Overlay"-layer would make sense at some point- typically, this could be shared among multiple instances of a MFD (think ND/PFD) - this would even be more efficient than the existing hard-coded od_gauge based instruments are currently. | |||
{{WIP}} | |||
Basically, you should look at Canvas-based MFDs and ask yourself which elements/layers are likely to be identical (or close enough), so that it would make sense to share certain elements (imagine background images, symbols, overlays and so on). Usually, this will reduce the workload for the Canvas system quite significantly, because an otherwise "complex" layer containing -for instance- OpenVG primitives will only ever be drawn/updated once during initialization and then merely referenced by instances of the actual instrument using it. You'll quickly see the merits of using this approach once you imagine rendering many (think 10+) instances of an ND or PFD. | |||
The basics on turning our existing SymbolCache framework into a LayerCache will be covered below: | |||
{{Caution|This code is still experimental and hasn't been tested yet ...}} | |||
<syntaxhighlight lang="nasal"> | |||
# this sets up a new Canvas texture 1024x1024 with 4 locations for cached layers (each 512x512) | |||
var CompassLayerCache = canvas.SymbolCache.new(1024, 512); | |||
# FIXME: check what else is required to cache SVG files loaded into a texture map ... | |||
CompassLayerCache.add(name: 'compass', callback: func(group) { | |||
canvas.parsesvg(group, "Nasal/canvas/map/Images/boeingND.svg", {'font-mapper': me.nd_style.font_mapper}); | |||
group.getElementById('compass').updateCenter(); | |||
}); | |||
# TODO: at some point, this could be a foreach loop moving all compass variants | |||
# into the LayerCache as per navdisplay.styles (compass, compassApp, compassMapCtr) | |||
# troubleshooting code to inspect the contents of the LayerCache ... | |||
var window = canvas.Window.new([1024,1024],"dialog"); | |||
window.setCanvas(CompassLayerCache.canvas_texture); | |||
</syntaxhighlight> | |||
=== Controllers === | === Controllers === | ||