I think it would be safe to join together the major parts that will never move and use them for KTTS Scenery
graph.removeAllChildren();
debug.benchmark(
graph.removeAllChildren();
);
zakalawe wrote:I would suggest to avoid the 'remove all children' logic, which is obviously unfriendly to the Canvas.
Hooray wrote:looking good - what is performance like, I am asking because of the removeAllChildren() approach you're using for clearing/redrawing each track (i.e. no caching/reuse of existing points), do you notice any impact on frame rate/spacing while updating ?
Hooray wrote:As a first step, I have edited the Canvas Snippets article to demonstrate how to draw quadratic/cubic curves (this should help lower the total number of Canvas path elements needed, because you're currently using a high number of line segments for approximating the curve):
http://wiki.flightgear.org/Canvas_Snipp ... enVG_Paths
Once this is working, I would consider creating an array (=Nasal vector) of path objects and simply update (translate, hide/show) those instead of using removeAllChildren() - so instead of invoking removeAllChildren(), you'd merely hide(), update()/transform() and show() the corresponding path elements
Hooray wrote:right, sorry for not being clear about it: I was referring to the reusing previously created point objects (as in the property tree), by merely changing their x/y positions - and simply hiding those not needed (using the .hide() method) - which means that you'd basically only have the allocation overhead once (i.e. during initialization).
The other obvious optimization is using a cubic/qudratic curve instead of hundreds of line segments (as I mentioned previously).
Basically, the idea is to have as little property I/O as possible - in terms of total property updates, but also total number of individual properties vs. "parametric" updates that don't create as much I/O (see the property browser to inspect how many nodes are created/removed during each update). In that sense, removeAllChildren() works analogous to delete() or free() in C/C++, whereas createChild("...") works like new/malloc - so you'd want to minimize those, and ideally use a data structure/drawing type that is appropriate (e.g. using a parametric curve instead of tons of line segments to approximate a curve)
TheTom posted these, and a few other, optimization suggestions in the original "fgplot" thread, including Nasal/Canvas code snippets.
You can use systime() and/or debug.benchmark() to see how much of a difference this makes for this particular use-case.
What is the performance like for people with older computers ?
Thorsten wrote in Mon Oct 05, 2015 5:28 am:What is the performance like for people with older computers ?
Don't know, don't care at this point.
There's ~90% of the avionics still not done at all, getting all workable is priority now, making it efficient is something that can be done later if it is a problem.
I am quite aware of that and agree with it, but there's a certain point of "proliferation" where it makes sense to revisit certain techniques - simply because other code is likely to have the same structure.
japreja wrote in Tue Oct 06, 2015 10:17 pm:I forget if I already asked before, but can we workout a list of completed and uncompleted systems, including a list of texturing/modeling(3d) work and who is doing what if at all possible? Regarding the cockpit if we can narrow it down to panels? maybe a todo checklist in the artwork folder?
Users browsing this forum: No registered users and 1 guest