Yeah, I'm also interested in any performance issues. For example a canvas is always redrawn if any property changes within the current frame, even if the same value is just written again or changes are too small to be noticeable. Also if a property of a hidden element/group is changed, the canvas is redrawn. Maybe checking if properties have changed enough will gain some speed, but I'm not sure if this will be noticeable at all (only if always the same values are written to the tree...)
right, I think now we're finally talking about the same thing
Yes, currently we have a fair amount of code doing fairly "dumb" things like running setprop() even though nothing is modified, I haven't yet optimized anything there - but this is straightforward to optimize at the framework level, Philosopher has come up with a clever MapStructure scheme, and once that's integrated/ported and used, things will be much better.
I don't really want to touch anything in map.nas, because it's obvious that it can go away completely due to Philosopher's work - even if that may take another 3-4 rainy weekends to fully materialize
Checking if a property has sufficiently changed may be useful, but it's also a form of "micro-optimization", I mentioned that when I talked about map ref-lat/ref-lon and range being possibly useful to determine if a symbol's position actually changed pixel-wise or not. Currently, the code will simply write lat/lon/range at framerate into the canvas tree, so those are not canvas issues, they are simple coding issues, because that will result in update() calls - on the other hand, we probably cannot expect Nasal programmers to be aware of "best practices" here - after all, Nasal is a garbage-collected language and people will usually not be aware of low-level internals like these, many users here first started programming due to FG and Nasal scripting.
"same value written to the tree", that's typically only happening when being stationary on the ground (or in the air) - so probably not worthwhile to optimize specifically for this case unless I'm missing something. But ignoring updates in hidden groups would make sense in my opinion. Also, does the canvas::map mode actually check the positions of symbols before they're drawn ? I am asking because in another test, I added tons of data (fixes) to a layer in range 320 - and then switched down to 80, and I was hoping that it would "filter" out invisible symbols due to current lat/lon/range settings, instead of updating everything ?
Completely automatic delegation of elements to "cache texture" will probably be not a feasible solvable problem.
I noticed that too a couple of days ago, when I played with using a 2nd texture as cache - because it's basically a placement problem, i.e. finding an area in the texture where the bounding box of the group fits in, so it's not completely trivial once there are possibly dozens of symbols in use.
If time allows I will also look into the array diff problem.
for now, we will just use the Nasal-space algo, but at some point extending NasalPositioned/NasalPositioned_cppbind would be helpful to make this faster, but obviously that's not a Canvas issue at all
Which fgdata clone should I use for the current state of the ND display?
We are working on the same repo/branch:
https://gitorious.org/fg/hoorays-fgdata ... ration-wipI think Gijs is waiting for us to finish before he proceeds.
From a performance standpoint, you only need to run the ND, either by starting the 744, or by using the ufo and pasting the snippet into the console I posted above, which will also work when using the ufo - but also to follow arbitrary AI traffic. When instantiated a couple of times, we'll see events/nasal and the canvas system being hotspots, I started using real profiling with the profiler-start fgcommand that you added.
Coding-wise, it's all still unoptimized and we're aware of it, there's lots of polling and setprop() calls at framerate, we will be using listeners and timers once MapStructure.nas is becoming more feature-complete, so that the map.nas stuff can be phased out, and all the draw/layer/model files replaced with Philosopher's sandbox'ed approach, which clearly is superior.