zakalawe wrote in Sat Nov 09, 2013 2:51 am:Looking good, can you get this working so we can replace the map-widget for 3.0?
We need to check what's missing, or rather, what would be useful to replace the map widget completely/properly. For example, as far as I know, we don't currently have any hooks into the replay/flight recorder subsystem, which is however what's used to show flight path history,right ? So the poor-man's approach would be using a timer and sampling the position separately, but having access to the replay/recorder system would be great for many other reasons, so exposing it via cppbind would be awesome.
BTW a minimum-range query doesn't make the C++ code much faster, so I would rather keep the API simple for FGPositioned.
yeah, but the point was not making the C++ code faster, the point was making the Nasal code faster when updating groups - by writing positions to the right layers/groups directly.
Otherwise, we would need to filter/sort stuff in Nasal space - or extend the canvas system with some filter that automatically sorts groups based on configured ranges.
So having a min-range query supported would allow us to significantly restrict each query down to relevant stuff, and directly adding it to the right layer.
Let's see what Philosopher has come up with - maybe he disagrees, but I'd find it useful (and simple enough) - especially in comparison to more sophisticated optimizations.
I'm not sure using fixed range-based layers is a good idea - it works for the ND, but for the map we might want 'smooth' zooming instead of steps.
right, but most NDs these days do work with fixed ranges - and currently, the queries are not flexible enough, and the original 744 code would actually lag a bit behind in certain ranges (160nm+), simply due to the sheer number of symbols being written to the property tree, all to a single canvas group/layer.
We can do fgcommand-profiling again to see if there are any low-hanging fruits still, but I doubt it in the meantime... some locations/ranges cause more than 1000 symbols per layer to be added, that MUST have an effect on frame rate - even regardless of Nasal-space overhead
I'm also surprised it's a good tradeoff in terms of memory use - for fixes and airports in particular, the large range causes a lot of cache and memory traffic, and since people rarely use 640nm range or zoom the map out that far, we'd like to avoid running the query until that range is requested. But maybe you already did this.
yeah, the original airport-selection framework already supported "lazy" updates like these - but that would inevitably result in frame latency spikes once the corresponding range is requested - which is why it might be better to still populate each "range group" as long as it's hidden, using much smaller queries/results per layer (incrementally) - we could then use split-frame loops to update invisible groups "in the background" and on activating a layer, only add what's missing still.
Otherwise, we need to think about some way to selectively update items, that's much more canvas-friendly - especially for use-cases like the map dialog, where simply calling removeAllChildren() is a simple no-go.
We'll see how clever Philosopher's scheme is, and if it's gonna be flexible enough to support the map dialog - but algorithmically, I haven't yet really touched the 744 ND code, and there's still some room for improvement. Otherwise, we need to convince Tom that we need some canvas-level instancing support to make 1000+ identical symbols less heavy. I already mentioned in another thread, that we could use a nested canvas and render such symbols as raster images instead - i.e. a Nasal/Canvas-space "caching" workaround.
From a C++ standpoint, we'd also need to look at supporting a more "pole-friendly" projection mode possibly - I think there's an issue for that in the tracker.
Also, exposing some more scenery/vector data would be nice to render more useful maps - or we'll need to revisit ESRI shapefiles again for that sort of stuff.
So if we really want to replace the built-in map dialog and the navdisplay for 3.0, there are some open issues still - including label decluttering etc. And I do believe that we need a way to benchmark each group/element/canvas at the core level, so that we can identify groups that are comparatively heavy to update, and see where time is spent (listener notifications vs. shiva) - otherwise, it's hard for us to tell where time is spent, because there are so many abstraction layers now, so that even core profiling doesn't provide good information anymore, and Nasal-space benchmarking would be insufficient.