Board index FlightGear Development Aircraft Cockpit development

Canvas NavDisplay performance

Discussion about creating 2d and 3d cockpits.

Canvas NavDisplay performance

Postby tdammers » Mon Sep 03, 2018 12:05 pm

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.
tdammers
 
Posts: 227
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: Canvas NavDisplay performance

Postby wkitty42 » Mon Sep 03, 2018 5:58 pm

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...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5695
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: Canvas NavDisplay performance

Postby tdammers » Tue Sep 04, 2018 7:51 am

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.
tdammers
 
Posts: 227
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: Canvas NavDisplay performance

Postby D-ECHO » Tue Sep 04, 2018 8:31 am

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
User avatar
D-ECHO
 
Posts: 1530
Joined: Sat May 09, 2015 12:31 pm

Re: Canvas NavDisplay performance

Postby Hooray » Tue Oct 30, 2018 7:39 pm

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.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11347
Joined: Tue Mar 25, 2008 8:40 am

Re: Canvas NavDisplay performance

Postby legoboyvdlp » Tue Oct 30, 2018 8:05 pm

The traffic layer was one that had quite a large impact on the A320 at least.
User avatar
legoboyvdlp
 
Posts: 7092
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: Canvas NavDisplay performance

Postby Hooray » Tue Oct 30, 2018 8:13 pm

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).
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11347
Joined: Tue Mar 25, 2008 8:40 am


Return to Cockpit development

Who is online

Users browsing this forum: No registered users and 1 guest