Wonderland Engine 0.7.3 was released with initial WebAssembly threads support. Learn about its impact on web graphics and WebXR in this blog post.
Threads allow the runtime to use more than a single processor at a time. Apart from additional performance, this enabled simultaneously
doing two or more tasks at once. The most noticable impact this has for Wonderland Engine is the now smooth framerate while transcoding basis textures.
Threads allow doing work simultaneously or simply doing work with more power.
With the later, CPU heavy tasks can be sped up, like transcoding multiple Basis
textures at the same time.
The former allows running rendering alongside CPU heavy tasks that span a big
portion of or more than a single frame.
Apart from loading assets, physics is a great example of this. While starting
to render the static parts of the scene, a game engine may simultaneously simulate
the dynamic objects.
Significance for WebXR
In WebXR, especially for Virtual Reality, rendering at a smooth framerate should
be the number one priority of your application.
Since that usually takes up most of the processing power and leaves only small
chunks of a few milliseconds, it is really hard to do longer processing tasks
To do these kinds of tasks, you need to use a service worker / thread to allow
rendering to continue while they run.
Implementation in Wonderland Engine
With the 0.7.3 release Wonderland Engine makes use of WebAssembly threads through
an internal job system if available.
If not available, it will fall back to loading a runtime that runs without threads.
You will find one of the first lines in the browser console to be either
“WASM Threads is supported” or “WASM Threads is not supported”.
While the Wonderland Engine currently only uses the job system to speed up and
smoothen the initial loading of the scene, we will gradually move more and more
tasks into threads.
This will improve the performance of your projects without you needing to change