I couldn’t agree more!
There are different issues with EFIS and the main problem from my experience and cross-testing (in modifying the default EFIS code) is not so much the rendering engine but the JS code.
I did try enlarging 2x the A320 screens for example so that it renders 4x more pixels and there wasn’t much perf impact doing this. It might still be a problem if this causes other CPU/GPU sync issues, but in itself the raw drawing part of EFIS is running good. The main problem however in my opinion is the JS code logic and the way they plug this all into the game:
-
CoherentGT is meant for GUI first and even only. This is the kind of tech you use to prototype your game UI first with easy to use layout framework (aka HTML+CSS), and easy to code interaction (JS). However, FS2020 is using this for gauge systems and drawing as well, and this is where I believe it is over pushing the framework for what it is not designed to do.
-
CoherentGT is rendering its own graphics with its own rendering engine (a separate DLL for DX11, DX12, Vulkan etc…) This limits a number of optimizations you could achieve in managing the EFIS rendering alongside your existing game rendering loop. It also imposes some GPU/GPU sync constraints because you can’t directly control where/when you’d push the EFIS specific draw calls inside the 3D world draw calls.
-
FS2020 is updating all EFIS at once. I’ve commented already how setting Gauge Refresh Rate HIGH is helping reducing stuttering because it would prevent FS2020 updating all EFIS at once from time to time only, which is causing a drop of perf. With HIGH, it is constantly updating and although you get less fps in the end, you don’t suffer the intermittent hiccups. I’ve recommended they instead update the EFIS in a round-robbin fashion, spreading out the computations over multiple frame (like they do for clouds, shadows, some reflections etc…).
-
Although in theory JS code is not interpreted but somewhat transformed to native code at runtime, it is still running in a single thread and this means the main game loop is dependent on this, most likely in a synchronous update way.
But the most important point to me about this tech, and the “bonus” of sandboxing 3rd party devs, is that there are no faster way to render EFIS than this technology in the simulator. In other simulators, you’d get direct access to the rendering context and can directly use the video card resources for your add-on if needed. With FS2020, the fastest pixel update you get is a CPU bound memcpy to a RAM buffer (unnecessary double allocation), and the fastest path rendering is either a low level vector drawing API in WASM (I don’t even know if this is hardware accelerated or handled on CPU with a backend like Cairo/Skia etc…) or the JS/HTML heavy weight machinery (for drawing a textured square, the entire stack is probably taking 100x resources you’d need).
I do believe the idea of such framework/middleware is sound in the great scope of things, but I believe even more they shall revisit its integration and the way it is processing unnecessary amount of data, and even its level of optimizations, because generally, these frameworks meant for UI are not coded to be the most efficient and optimized implementations. The game render loop is dealing with tight frame time budgets, the UI framework is dealing with abstracted user interactions where rendering is an after thought. Using UI framework for real-time game loop rendering elements and logic is definitely not what it is supposed to be nor coded for in my opinion, but I might be wrong.
You might want to support these “somewhat” related topics:
Coherent gt draw - FPS limiting glitch - Archives / Bugs & Issues - Microsoft Flight Simulator Forums
[BUG/FEATURE] EFIS Screens Problems and Solutions for higher legibility