WASM: Run C++ tests in webassembly environments
Currently, VTK C++ tests are run only on x86_64 desktops. VTK advertises support for the wasm32-emscripten architecture and there is a CI build job which ensures that VTK continues to compile with emscripten, which is great, but not enough because there are folks who use vtk.wasm in production. It is currently impossible to know whether a merge request breaks something in wasm without someone sitting down to code up a test case manually. This is pointless because there are already a large number of C++ tests in VTK.
So far, we've been able to identify and fix:
- regression introduced by !10356 (merged) (fixed by !10521 (merged))
- regression introduced by !10403 (merged) (fixed by !10466 (merged))
- !10503 (merged) could've easily been caught in a unit test.
- Somebody broke vertex visibility and the feature to render vertices as spheres. Still don't know when/where it occurred.
In all the above cases, we could have saved a lot of time and resources if the C++ unit tests in VTK source ran automatically in the browser too. It's not really all that complicated or new and emscripten has been doing it for a long time.
After looking at emscripten's automated workflows, here's some ideas:
- Have two test jobs for now. (firefox, chromium) Can be expanded to include nodejs for pure compute and wasmtime for wasi based tests.
- Since the priority is rendering, the focus is on browsers. It's best to not use the OS provided browsers, as we do not wish to pollute user data directory. So, download firefox, chrome tarballs and set the
BROWSER
environment variable to something like:# For firefox export BROWSER="/root/firefox/firefox -headless -profile /root/tmp-firefox-profile/" # For chromium export BROWSER="/root/chrome-linux/chrome --enable-unsafe-webgpu --no-first-run -start-maximized --no-sandbox --user-data-dir=/root/tmp-chromium-profile --enable-experimental-web-platform-features --remote-debugging-port=1234 --enable-experimental-webassembly-features --js-flags=--experimental-wasm-memory64 --experimental-wasm-stack-switching --experimental-wasm-type-reflection --media-cache-size=1 --disable-application-cache --incognito"
- Write a python script (
vtkBrowserTestDriver.py
) to launch browser and run the wasm tests. This script can use the builtinwebbrowser
python module to open browser windows.ExternalData_add_test
invtkModuleTesting.cmake
could run this python script with the remaining test arguments.
python vtkBrowserTestDriver.py --executable vtkRenderingCoreCxxTests.js --args -D ... -V ... -T ...
I'm currently optimizing the memory usage in VTK OpenGL ES polydata mapper. As it could potentially break a number of things which are hard to test manually, I plan to come up with basic testing infrastructure as outlined above soon.