IDG A32X Development Archive - Closed

[V12]

First report of that problem is here :
viewtopic.php?p=315784#p315784

[Octal450]

Yes.

I first encountered it on my laptop.

J

[legoboyvdlp]

First of all, I'd suggest to make sure that you do some testing to see if you understand where/why performance drops (rendering vs. updating) - i.e. do some benchmarks first, and then take it from there. It's pointless to provide coding advice without knowing that you are actually facing that exact problem.

@Hooray
In terms of this, we have tested and disabling Canvas brings performance from 11 fps on my new hardware (but 100ms latency, making it far smoother than my earlier 10fps which gave 200ms latency...) to 24-27 fps. Enabling ALS, landmass, and model shaders has no effect on fps: seemingly indicating that the bottleneck is calculating all the Canvas. We'll be heavily optimising Canvas over the coming weeks, if we find the issue

[Octal450]

On my system, I loose about 4-5FPS, but lego looses over 15.

Kind Regards,
Josh

[V12]

When I switch on TCAS on both NDs, I loose 10-15 fps.

[Octal450]

That is a different issue. We are looking at that later.

Kind Regards,
Josh

[V12]

OK.

[Hooray]

we have tested and disabling Canvas brings performance from 11 fps on my new hardware (but 100ms latency, making it far smoother than my earlier 10fps which gave 200ms latency...) to 24-27 fps.

it would make sense to disable different parts of the Canvas, for example:

• disable rendering
• disable updates of the Canvas

That way, you can see if the problem is rendering related or if it's due to your Nasal code that may be poorly structured.
A Canvas that isn't updated at all, should basically render a static quad only - disabling rendering only (e.g. via invoking .hide() on the top-level root/group node), will still update things, so that you can determine more facts.

In addition, you can also check out other, lower-level, groups (or elements) to narrow down what is going on.

In the majority of cases, it's Nasal code that is poorly-structured and updating/rendering (re-drawing) the Canvas texture too often - the other common issue is a staggering amount of property accesses (getprop/setprop)

That is one of the reasons why I repeatedly suggested to check out Richard's MFD framework, which provides building blocks that can be used to better structure the Nasal code, e.g. using a "data provider" abstraction - which would mean that 100+ getprop() calls won't get executed, but use the memoized (cached) result from the first invocation during the same frame.

There's other optimizations that can be done obviously - but the first step is really doing some benchmarking first to come up with a theory what is going on, and then take it from there.

In general, Nasal-space data structures should be preferred over property tree use, if the corresponding state doesn't need to be "shared" - for example, Thorsten ended up restructuring his Advanced weather code (local weather back then), because he was using the property tree for all kinds of stuff that didn't have to live in the global tree.

These days, things are no longer as clear-cut unfortunately, especially because many fgfs subsystems don't really have any dedicated Nasal APIs (bindings), so that the property tree is the sole mechanism to set up AI traffic nodes, modes or talk to effects/shaders.

[legoboyvdlp]

To be honest, you are going over my head a bit but I'll try and make sense of what you want us to do soon

[Hooray]

okay, using different words to say the same thing, imagine it like this:

Imagine you are an artist (i.e. the Canvas system), and you are supposed to not just draw a single static image, but a bunch of animated images that are viewed in order.

You have a list of things/primitives (Canvas elements) to be drawn (lines, circles, text, images, paths), that list may change
over time (ever frame) - if it doesn't change, you can reuse the previous list, or even the previous image (less work for you) - if it does change, you have to delete the previous image (and all underlying lists) and redo everything from scratch.

In other words, you have more work to do when the list of things changes (your "todo list") - and then, there's the overhead that comes from actually EXECUTING that list - imagine, you have 10 things to draw, vs. having to draw 100 things - it will take you longer obviously.

In addition, your list may contain "pointers" - as in asking you to do stuff like draw something that you know nothing about, i.e. you have to go to wikipedia to look up the details - which will take obviously even longer (imagine wikipedia being the equivalent of the property tree, i.e. getprop/setValue() calls)

Thus, asking you to draw a single number say "10" is less work for you, than asking you to look up the birthdate of Nelson Mandela, let alone do a computation using different dates

And then, there's complex things to draw, vs. relatively simple stuff.

So, imagine a Canvas instrument like doing a live video (stream) using dozens, and possibly hundreds, of live parameters retrieved from the property tree - with various calculations involved to animate the video (instrument) properly


Therefore:

- stop rendering (hide the canvas) = that way, you can determine the impact of drawing vs. not drawing the Canvas (texture)
- stop updating/stop changing properties of the canvas (elements) = keep on rendering/re-drawing the Canvas, but don't actually update any data in the property tree - the Canvas will be shown, but not being animated/updated - it will be a static image, akin to a photograph that is using outdated properties

doing both at the same time, will tell you the overall impact of not updating/rendering the whole Canvas instrument


Imagine a very simplified equation saying
canvas_performance_drop = canvas_rendering_impact + canvas_updating_overhead

By changing rendering overhead or updating overhead to 0, you can determine what else is going (it's not as simple as that, but will do for starters, and hopefully allow you to draw make more informed decisions)

[Octal450]

OK, thanks.

I'll take a look at it once I resume development.

Kind Regards,
Josh

[V12]

Bug or feature ?


Ground speed is equal with TAS, but there is tailwind 14 kts. IMHO, GS should be 499 kts. Or am I wrong ?

[Octal450]

@V12

Kind Regards,
Josh

[V12]

Rgr, check https://github.com/it0uchpods/IDG-A32X/issues/135

[emdc]

Is there anywhere where we might be able to download an older version of the A32X with the a318/19/21 included? I used to have them on my computer but must have deleted it at some point. Thanks!