-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for 7 compression plugins #35
Conversation
This was a limitation of Chrome and Chrome-based browsers (including headless, I'm sure) until recently. The limitation was removed months ago (just before the HDF5 User Group meeting - I talked about it there). Simplest solution is just to upgrade to a more recent browser version. The issue doesn't seem to affect other engines (like those in Safari or Firefox) |
Right, hmm this sucks then, because I'm on the latest version of VS Code... Maybe VS Code or Electron enforces this limitation internally on purpose to avoid blocking the main thread. 🤔 |
I'm guessing it means they're still on a slightly older JS engine - eventually the problem will go away (maybe?) |
If you are going to move it to a worker, it seems like you could reuse the h5grove api definitions and write a worker that provides those endpoints. I don't imagine that would be too much work, and could be useful in the browser too. |
Have you looked into preloading the plugins, as described here? https://emscripten.org/docs/porting/files/packaging_files.html#preloading-files |
29511e4
to
429bb1f
Compare
With version of Chromium bundled with Electron 27, the compression plugin files are successfully compiled to WebAssembly on the main thread when loaded. https://code.visualstudio.com/updates/v1_86#_electron-27-update
Well... seems that patience pays! 😂 With the upgrade to Electron 27 in VS Code 1.86.0, the error is gone and the plugins load successfully. 🎉 I'll keep the goal of moving to a worker on the back burner, as this is still the better approach in the long term. |
Took me a while to figure out how to fetch the plugin files from the webview, but I got there in the end. Unfortunately, I'm hitting the following issue with some of the larger plugins (LZ4, ZStandard, etc.):
The webview fetches the plugin files correctly, and they get written to the Emscripten file system as expected. The problem seems to occur when h5wasm reads the compressed dataset and HDF5 tries to load the appropriate plugin dynamically.
@bmaranville I assume there's no other workaround than to move @h5web/h5wasm to a worker, right?