- change navdisplay.mfd to call predicate(nd,symbol) in the foreach loop - all the predicates in navidplay.style can then be changed to only show()/hide() or update() if necessary - avoiding redundant/unnecessary state changes, will keep canvas happy - equally, passing the symbol directly, will reduce hash lookups (which currently happen way too often):
- Code: Select all
var apply_state = func(condition_cb, action_cb) {
if (condition_cb()) action_cb()
}
- Code: Select all
{
id: 'compassApp',
impl: {
init: func(nd,symbol),
predicate: func(nd, symbol) (nd.get_switch('toggle_centered') and nd.in_mode('toggle_display_mode', ['APP','VOR'])),
is_true: func(nd, symbol) {
if(nd.get_switch('toggle_true_north'))
var hdg = nd.aircraft_source.get_trk_tru();
else
var hdg = nd.aircraft_source.get_trk_mag();
symbol.setRotation(-hdg*D2R);
symbol.show();
},
is_false: func(nd, symbol) symbol.hide(),
},
},
- use caching for symbols, see the VOR.symbol and DME.symbol files for examples on doing this correctly using the SymbolCache
- don't re-draw redundant layers: for instance, the compass rose on the ND is redundant, no matter how many NDs you are displaying - it makes sense to treat the compass rose as a dedicated layer (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 to do, because the compass rose will rarely -if ever- need to be updated - 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. We kinda discussed the technique a few times already - i.e. introducing the concept of an "Overlay"-layer would make sense - 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
- when doing route-drawing (or any other complex layer), apply range based filtering - in the case of waypoints, just do a range check using geo.nas helpers - in the case of waypoint legs, you need to ensure that at least one waypoint is within range to draw the whole leg, otherwise (if both waypoints of a leg are out of range), you can skip the whole leg - the latter should help draw complex routes, especially in low-range settings, because most of the rendering can be skipped - you merely need to adapt searchCmd() in WPT/RTE (lcontroller) to skip certain waypoints/legs there.
- finally, when dealing with complex layers that may have dozens of active symbols/labels shown, consider adapting the .del() method in the scontroller file to append(layer.free, me) - you only need to invoke .hide() first - what this will do is maintain a "free list" of symbols/labels that were previously allocated but that are no longer in use. By changing the .new() method you can then re-use/recycle those canvas elements, so there should be less of an overhead when allocating new nodes (think toggling range).
None of these should require any C++ knowledge, and you also don't need to know how to build FG from source - I am sure we can come up with more ideas to squeeze out some more performance.
As long as people are already familiar with Nasal and Canvas basics, most of these can be quickly applied.