FG1000 Performance hit

[dom_vc10]

Hi

I have tried a couple of aircraft with the FG1000. This seems to more than halve my framerates for example in the Cessna182 s. When just using the good old steam cockpit I hold around 40fps when using the modern cockpit I will get 10-15. My CPU is pretty old generation and I know it can't hold up so well these days but is there something that I could potentially edit/change that may help a bit here?

[benih]

No, it’s a known issue and the internals of the fg1000 needs to be tuned.
Nothing you can do on your side (except, of course, to learn nasal and help)

[V12]

Similar problem has terrain and WX radar on A320family navigaition display This is not problem of the FG1000, but technology behind Canvas. When I worked on Concorde, I had same trouble with traffic layer for TCAS, I solved them with filter on the traffic speed, only airplanes moving faster than 35 kts was on the instrument.

[dom_vc10]

I did a bit of forum searching. Seems the same info all around. Good to know it's not some issue with my system at least.

Maybe in a few years I can get some knowledge of nasal, need time to study.....

[Hooray]

The explanation is not as simple as some people make it sound, there are a couple of options ... depending on your background.

SImply stating that the Canvas/Nasal stack is too slow, is insufficient to explain what's really going on.
Also, just saying "learn Nasal to help" is unlikely to be fruitful: the people who wrote the whole Nasal/Canvas back-end and the FG1000, are pretty familiar with Nasal and Canvas internals. And most of them are core developers.
Thus, it's unlikely that a person who is only just "learning Nasal" is going to be able to help with optimizing the FG1000 or the Nasal/Canvas stack in particular.

At this point, it's more helpful to get involved in troubleshooting - i.e. testing and reporting back.
For instance, by running the built-in profiler: https://wiki.flightgear.org/Built-in_Profiler
We can walk you through the process of just profiling the FG1000 specifically.
Obviously, that assumes that you're able to rebuild fgfs from source (however, I am not sure if any of the nightlies come with built-in profiling support?).

Another option would be getting involved in Nasal space benchmarking: The FG1000 uses the Emesary framework, so it should be pretty straightforward to use the debug.nas module and specifically the benchmark() API to profile the FG1000 in scripting space.

So there really are many options at this point, and you don't necessarily need to "learn" Nasal to get involved in troubleshooting Nasal/Canvas performance.

Sooner or later, another option is going to become feasible, namely running certain Canvas based avionics outside the main loop - moving the rendering portion into a dedicated OpenGL context is well-understood (and already possible), but comes with its own issues:

https://wiki.flightgear.org/Canvas_Threading


At some point in the future, we will also have the discussion to assign a single independent Nasal interpreter instance to such standalone avionics, and run that inside a SGThread based SGSubsystemMgr shell - including a private property tree, and a private event manager (for timers). At that point, we will have most building blocks in place to create Canvas based avionics that no longer need to run inside the FlightGear main loop - this is largely facilitated by Jules CompositeViewer work: https://wiki.flightgear.org/CompositeViewer_Support

If you care about these features, please do get involved in regular testing, ideally using aggressive OSG threading and additional pager threads:

https://wiki.flightgear.org/Howto:Activ ... PU_support
https://wiki.flightgear.org/Howto:Using ... er_Threads

Another important feature to test in conjunction with threading is reset/re-init: https://wiki.flightgear.org/Reset_%26_re-init

So, if you can, please get involved in testing FlightGear - ideally, by running FlightGear inside a gdb/debugger session so that you can provide backtraces whenever you can reproduce a problem - alternatively, by using nightlies and the built-in sentry tooling.

All of this is to say, you can definitely be part of the solution without having to be a programmer - testing goes a really long way to iron out remaining issues to hopefully fix up/improve features like the FG1000.

Obviously, for programmers, there are many other options, too - and we can discuss those in the Canvas sub forum