Coherent GT Draw stutter, only in modded default planes

[ToxicResonance 1]

Hi everyone,

I'm a huge fan of the WT CJ4 and the FBW A320, but I find both of those planes unflyable due to a stutter that happens every few seconds on the Coherent GT Draw thread. The game runs perfectly smooth for a few seconds at a time, then will freeze for around maybe a quarter or an eighth of a second, then resume running smooth, rinse and repeat for the entire flight.

Worth noting that this happens in exactly 0 addon aircraft. The JF Arrow, Aerosoft CRJ, and the Carenado M20R all run perfectly smooth and never drop frames. It's only the default planes that do this.

I've searched around, but I can't find anyone else talking about this, but when I watch videos of gameplay with those planes, I can see the stutter happening there too.

Performance at least on my end shouldn't be an issue, I'm running a Ryzen 7 3700x and an RTX 3080. And like I said, addon planes are buttery smooth. It looks like these default planes are just hooked up to the CGTD thread in a way that causes it to drop frames every so often. I love these mods though so if anyone has any ideas that would be great. I've tried changing the glass cockpit refresh rate setting but that just makes the stuttering way worse.

[fogboundturtle 2,708]

Change instrument refresh rate to medium

[marsman2020 1,310]

Or set instrument refresh rate to high.  I've seen some posts that medium can cause those spikes, where as high lowers overall FPS somewhat but has less spikes due to the faster pacing of the updates.

[somiller 694]

I find more or less the same thing. The modded TBM and WT CJ4 seem to exhibit more or less identical stutters and same with the FBW 320, but with reduced fps. I have played around with the glass panel refresh a million times and always end up back on low or medium because high is too much for my system. The Aerosoft CRJ on the other hand gives me virtually flawlessly smooth performance and consistently higher fps than all of the above. If they could fix the quirks with the CRJ AP it would be a star.

[Silicus 850]

This sim is broken with this since update 3. Frame rate is expectable after the latest 'hotfix', but not like it was before. Something is putting the brakes on!

I guess we have to wait for another update, which might brake something else, but no, I am staying positive!

[MrFuzzy 2,118]

1 hour ago, Silicus said:

This sim is broken with this since update 3. Frame rate is expectable after the latest 'hotfix', but not like it was before. Something is putting the brakes on!

We have the right to say that the sim is "broken", it still has issues, but only taking into consideration what MS put in the package. They cannot be responsible for the bugs and the performance of a million of community mods.

Having said that, I don't think the mentioned aircraft have a performance issue at all: they are just more demanding than the default aircraft because they are more complex, have more features and more stuff running under the surface.

[dga711 95]

10 hours ago, ToxicResonance said:

Worth noting that this happens in exactly 0 addon aircraft. The JF Arrow, Aerosoft CRJ, and the Carenado M20R all run perfectly smooth and never drop frames. It's only the default planes that do this.

Afaik these don't run glass cockpits on the JS/Coherent side but in C++/WASM or use less displays of js stock instruments.

Most mods started out in the beginning of MSFS as "lets add more things" and push the boundaries of what you can do in the Sim. This approach of doing instruments using web tech is quite new in the space, so everyone is learning along the way as problems start to show up.

The mod community, FBW and us learned a lot in the past months as to what is inducing some of the performance problems we see on glass cockpits using JS.
So for example FBW is also working on optimizing the instruments (afaik going the React route) by implementing them in a different way.
We have also drawn our conclusions and will apply those learnings in the future.

  

Edited April 8, 2021 by dga711

[MattNischan 3,778]

To add on to what DGA is saying,

I'm actually surprised to hear that performance is worse on our CJ4 compared to the default aircraft. We have done some optimizations that should reduce stutter frequency and in general on most folks machines we get about 5-7fps better than the stock plane.

That being said, the biggest issue with building on what is stock is that they weren't necessarily coded with the constraints of a garbage collected language in mind. For the lay person, in JS, the language does memory management for you. While this greatly simplifies things and totally eliminates an entire class of highly critical bugs, it does mean that code can allocate somewhat haphazardly; later, the JS runtime has to go and deallocate this memory in sweeps, and these sweeps are called garbage collection.

Garbage collection has to pause the whole runtime while it completes, and this can manifest in intermittent hitches.

This is not to say that languages like these are unsuitable for real time applications, just that like in C++, one needs to know the right coding strategies and techniques to avoid generating too many allocations. Having coded some performance sensitive systems in managed languages, I know where these kinds of pitfalls can be easy to fall into.

Going forward with our future work inside and outside the sim, we will be applying these techniques at a fundamental framework level, so hopefully everyone can take better advantage.

-Matt

Edited April 8, 2021 by MattNischan

[cavaricooper 2,613]

L’audace, l’audace, toujours l’audace!

Merci

🙂

 

[ToxicResonance 1]

6 hours ago, dga711 said:

Afaik these don't run glass cockpits on the JS/Coherent side but in C++/WASM or use less displays of js stock instruments.

Most mods started out in the beginning of MSFS as "lets add more things" and push the boundaries of what you can do in the Sim. This approach of doing instruments using web tech is quite new in the space, so everyone is learning along the way as problems start to show up.

The mod community, FBW and us learned a lot in the past months as to what is inducing some of the performance problems we see on glass cockpits using JS.
So for example FBW is also working on optimizing the instruments (afaik going the React route) by implementing them in a different way.
We have also drawn our conclusions and will apply those learnings in the future.

  

 

6 hours ago, MattNischan said:

To add on to what DGA is saying,

I'm actually surprised to hear that performance is worse on our CJ4 compared to the default aircraft. We have done some optimizations that should reduce stutter frequency and in general on most folks machines we get about 5-7fps better than the stock plane.

That being said, the biggest issue with building on what is stock is that they weren't necessarily coded with the constraints of a garbage collected language in mind. For the lay person, in JS, the language does memory management for you. While this greatly simplifies things and totally eliminates an entire class of highly critical bugs, it does mean that code can allocate somewhat haphazardly; later, the JS runtime has to go and deallocate this memory in sweeps, and these sweeps are called garbage collection.

Garbage collection has to pause the whole runtime while it completes, and this can manifest in intermittent hitches.

This is not to say that languages like these are unsuitable for real time applications, just that like in C++, one needs to know the right coding strategies and techniques to avoid generating too many allocations. Having coded some performance sensitive systems in managed languages, I know where these kinds of pitfalls can be easy to fall into.

Going forward with our future work inside and outside the sim, we will be applying these techniques at a fundamental framework level, so hopefully everyone can take better advantage.

-Matt

 

Thanks for the replies guys, I really love your work. I just love that other people love this hobby so much that they work hard to improve it for free. 

 

That's unfortunate that the stutter seems to be inherent to the stock planes with no way to remove it. My hunch is that Asobo didn't know about open source improvement projects for stock planes (or that they didn't exist) when they started making the planes. So I bet the decreased workload from implementing the gauges that way seemed to be the way to go because they thought that the stock planes would only be filler while enthusiasts would go for addon aircraft.

 

I'm not a programmer so you'll have to forgive my ignorance. What's the prognosis like for a situation like this? Can the gauges be ported over to a more efficient language? Will the upgrade to DX12 help?

 

[RXP 2,338]

@dga711 @MattNischan

I've posted something puzzling me about the ATC Panel JS/HTML yesterday:

https://www.avsim.com/forums/topic/598106-flight-sim-blog-performance-fix/?do=findComment&comment=4513562

 

[MattNischan 3,778]

@RXP I don't know that I would make any claim that Coherent GT, as a framework, is slow.

You just have to be smart about updates: if you do a bunch of things that hit GC or you have to make a ton of large scale DOM redraws during a frame, you'll run into issues. I haven't looked at all closely at the ATC panel code, but it does seem to trigger a large amount of draws. I'm sure the item list management could be improved to avoid those.

But, as can be seen by the WT G1000 0.4 beta, with the right techniques (proper CSS layers, avoiding DOM redraw and/or repaints and invalidations, not allocating so much, etc), you can get Coherent thread times into the 1ms to sub 1ms range.

-Matt

[MattNischan 3,778]

40 minutes ago, ToxicResonance said:

That's unfortunate that the stutter seems to be inherent to the stock planes with no way to remove it. My hunch is that Asobo didn't know about open source improvement projects for stock planes (or that they didn't exist) when they started making the planes. So I bet the decreased workload from implementing the gauges that way seemed to be the way to go because they thought that the stock planes would only be filler while enthusiasts would go for addon aircraft.

 

I'm not a programmer so you'll have to forgive my ignorance. What's the prognosis like for a situation like this? Can the gauges be ported over to a more efficient language? Will the upgrade to DX12 help?

It's not really that there's no way to remove it, just that the code would need to be refactored to adopt the kinds of strategies to which I'm referring. It's not really that they're coded terribly, which I don't want to imply. It's just that they could use a little more care in some of these areas.

The choice of programming language here is not really at issue, in my opinion. It's just as easy to make something perform badly in C++ as it is in any other language. Each language has its own performance characteristics and learning what to do or not to do in different language paradigms is really just a matter of time and experience, and in some cases, trial and error on the platform you're targeting (sometimes doing one thing for perf on one platform negatively impacts perf on another, for example). In the same vein, DX12 will not bring improvements here (as an aside, people might need to meter their expectations on DX12 as a performance silver bullet: if done extremely well it can sometimes net some single digit percentage performance improvements, but moreso it's about featureset, for a project like this).

The prognosis here is twofold: one, as I mentioned briefly in the last MSFS dev Q/A we will be bringing our stuff to the sim proper, and that also means our performance learnings. But additionally, a big goal is making it easier to "lead developers to water" so to speak: to make it so that they fall into the "pit of success" from a SDK and framework perspective on the JS side with something that leans heavily into driving developers towards these proper strategies and patterns.

-Matt

[somiller 694]

18 hours ago, MattNischan said:

To add on to what DGA is saying,

I'm actually surprised to hear that performance is worse on our CJ4 compared to the default aircraft. We have done some optimizations that should reduce stutter frequency and in general on most folks machines we get about 5-7fps better than the stock plane.

-Matt

Matt,

I hope it wasn't my earlier comment that led you to the above statement, I certainly didn't intend to imply the WT CJ4 performs worse than the stock CJ4. I honestly don't know how they compare because I wouldn't fly it without the WT mod! The WT mod is a masterpiece especially considering the stock base that it's built on.

[kdfw__ 539]

i had the same problem with coherentgtdraw timing blowing up after flying in/around photogram area in the vc view. flying back and forth between EGLC and EGLL, frames would go from the 30s to 10s with coherent draw going crazy.

this is what mitigated it on my setup (mainly VR rig):

HAGS=on

NVCP

pwrmgt=max perf

thread opt=on

VR pre-render=2

it's all pretty smooth now and looks great.

however, turning HAGS=on isn't working great for DCS...