Canvas NavDisplay performance

[tdammers]

Hi all,

I did a bit of experimenting, and tried using the canvas-based NavDisplay found in FGDATA to replace most of the MFD of the CRJ700 family. It starts to look alright, but it seems to ruin performance - with the vanilla CRJ, I typically get around 20 fps, but with the NavDisplay version, frame rates plummet below 10 fps. I have no idea why this is; the 777, from which I borrowed a lot of the MFD code, seems to perform OK.

[wkitty42]

you are not updating properties to often, are you? a lot of canvas slowdowns i've seen have ended up being updating properties that have not changed since the last update...

[tdammers]

Hmm, let me check. I did add a few property rules and aliase because the aircraft's autopilot uses incompatible ones. I'll go look what happens if I remove those.

[D-ECHO]

You might want to have a look at the CRJ200 (https://github.com/D-ECHO/CRJ200) I think it already has a more or less well working canvas NAV display

[Hooray]

it would be interesting to see if the issue can be reproduced using any of the ND related MapStructure layers, or if the issue is specific to the ND - which is known to contain pretty problematic code patterns, but which is a self-contained piece of spaghetti code that can be updated rather easily.

[legoboyvdlp]

The traffic layer was one that had quite a large impact on the A320 at least.

[Hooray]

okay, thanks for sharing - however, it'd be a bit surprising if this doesn't also show up when using said layer in isolation, e.g. via the map-canvas dialog ?

Under the hood, it's exercising the same code paths - so if there is any significant difference in terms of performance, that would suggest that the front-end code (the ND mess instantiating the MapStructure layer) is doing something really stupid (I should be allowed to say that, because I was involved in reworking said code to make use of the MapStructure framework, back when it had all sorts of performance issues, i.e. when it wasn't optimized at all).

Don't get me wrong, I am definitely not emotionally attacked to the ND code or the underlying MapStructure layers, but the reasoning behind that splitting/separation was indeed to be able to more easily profile/optimize and update back-end logic without having to touch tons of front-end (read: aircraft-side) code.

The long-term idea was to establish MVC concepts at the Canvas level and make it possible to create dynamically reconfigurable Canvas primitives in Nasal space, and register those as native Canvas elements, along the lines of the write-up here: http://wiki.flightgear.org/Canvas_Devel ... FlightGear

Thus, what the MapStructure framework is doing, should just be considered one iteration of an ongoing process.
And if this should ever materialize beyond MapStructure.nas, that would very likely mean that the ND mess can go and be replaced with something more aligned with the MVC way of doing things (prototyping new elements in scripting space, registering those via sc::Group and providing support for customizations via element-level inheritance along the lines of Tim's effects and their property-based inheritance mechanism).