The only advantage to C++ in the context of WASM modules is supporting legacy
code. For everything else, it’s the wrong choice of language. Javascript would
lower the barrier to entry for new developers, and massively speed up
development for existing developers.
Is there a reason why you would want a JS WASM target specifically for this?
It is already possible to use JS in the sim via the Coherent framework, which
powers the default avionics. -Matt | Working Title
@mattnischan; Yes, the performance hit with coherent is unacceptable. Even the
“low” setting for glass cockpit refresh rate has a large impact, thus I
imagine running an update every frame would completely kill performance. That
said, Coherent could possibly be a workable solution for logic instead of just
UI/panels if it were to run on a separate thread
You’ll have to take my word for it that isn’t a function of the Coherent
framework and is instead just not very well optimized code. Properly optimized
code using the correct performance techniques is near native speed. As an
example our upcoming G1000 NXi PFD runs the entire PFD in about 1ms. Coherent
already runs mostly on a separate thread, but coming in an update it will be
separated more or less completely. -Matt | Working Title
Good to know; I hadn’t actually tried it, so it was just an assumption. Would
be great to know what best practices are for maintaining high performance with
Coherent; I would imagine it is different to developing for the browser or V8?
- <https://coherent-labs.com/Documentation/cpp-
gt/d9/df1/performance_guide.html> There are some good tips in this performance
guide from Coherent. - Don’t redo things every frame when data doesn’t
change. We are heading into a more event based approach, where DOM will only
be manipulated when the underlying data actually changes. - Garbage
Collection is something Coherent is not very performant at. Minimize assigning
variables and throwing them away. As Matt already said, there will be more
improvements on that side coming from Asobo in the coming updates. -- dga |
Working Title
The first point sounds like something that could be addressed with a reactive
framework like React, have you guys tried using React or something similar in
this context?
React is good for avoiding unneeded DOM shuffling but really terrible for
generating garbage. During its reconciliation phase, a lot of temporary
objects are allocated which makes it unsuitable for things that have many
components updating every frame, as that puts serious pressure on the garbage
collector. Something else to note is that even in WASM, this problem doesn’t
go away, as the JS garbage collector is baked into the output WASM code
itself. Managed languages require different strategies than unmanaged
languages when writing for tight game loops. -Matt | Working Title
This helped me the most when using React on complex, often-changing UIs: -
Memoize as many components as possible - Avoid inline SVG for static
elements. Make everything that doesn’t change an svg file. While this
logically has very little effect on rendering, the difference is that React
will never see the DOM nodes for that complex SVG and will instead see one ``
tag. This reduces work during diffing / reconciliation. - Make sure to round
/ toFixed often-changing values appropriately For static UIs like FMCs, I have
not found this to be necessary, but every cycle counts!
Also: the Coherent debugger is an amazing friend! Just keep in mind that it
seems to include GC pauses in function calls as being that function executing
code.
You can technically already use whatever language you want that compiles to
WASM. Over at FlyByWire we are using rust instead of c++. JavaScript (and by
proxy typescript) is an interpreted language and cannot be compiled to WASM
but you might find AssemblyScript, a typed subset of JavaScript which targets
WASM, to be interesting.
To be honest, 1ms for the PDF, so at least 2ms for both screen, (3 with 3
screens configurations aircraft) is good but not a high performance. At 60fps,
you have 17 ms for each frame, 3 ms just for the G1000 is huge if we think
about all other things the sim has to manage at each frame. What i say is you
are doing the best with this framework, but you are limited by it. Perhaps
this multilayout framework made for UI was not the best choice for real time
complex avionics in a sim.
lol 1ms for entire pfd? wasm can do in 1ms for entire aircraft sim and display, JS or any stupid descendant of it are just stupid language for simulator
Reviving a thread that was left to rest since December 2021 just to state such a useless and offensive (and potentially wrong) statement leaves me speechless.
Please re-read our Code of Conduct and respect it.
Best regards,
Eric / Asobo
4 Likes