-
Notifications
You must be signed in to change notification settings - Fork 58
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
Improve native WebAssembly compilation #96
Comments
Looks like so far we are blocked by num not compiling due to rustc-serialize not compiling. So we either have to wait for num to switch to serde rust-num/num#357 |
With this PR chronotope/chrono#137 revived we could compile chrono on wasm too, we'd just need to bring our own Instant::now() and Utc::now() |
I began implementing this by not compiling the crates that don't work for the wasm target and polyfilling them. So that means mimicking relevant behavior (like parking_lot's locks being replaced by std's) and ignoring some other behavior for now (DateTimes are completely ignored, they are just empty structs) |
I got mostly everything working. Things that need to be fixed:
|
A lot of crates are polyfilled in the platform module. Most of the polyfills work more or less correctly. Go to issue #96 for more information.
Looks like it was easy enough to just use the png crate to implement all the PNG Encoding / Decoding. So the only thing missing is chrono without the time dependency. |
Welp, it's actually somewhat broken. Whatever, at some point image will compile with the target, so I'm fine with that. It only really affects Llanfair files anyway. |
Nvm, turns out it was very easy to fix :) |
A recent upgrade of all the dependencies allowed us to get rid of all the polyfills except the one for chrono and the std::time stuff. |
Rust now uses LLD to link native wasm code, reducing the stack size from 1 MiB to 64 KiB. That's quite a large drop, considering we are using 5 MiB with emscripten. So we should probably check if everything still works and there's no stack overflows happening. |
Are we still blocked by the chrono PR? |
Well we have everything stubbed out, but yes, the chrono PR doesn't seem to have progressed at all. |
This is now ready to be finished: chronotope/chrono#236 (comment) |
And it's still blocked by something. Apparently you can't have target specific features: rust-lang/cargo#1197 :( |
That makes no sense. I don't see why you can't have target specific |
It's just not implemented correctly in cargo to support this properly atm. |
I'd really like to switch LiveSplit One over to the native wasm target (and potentially just throwing out the emscripten target for now). I've had to tell multiple people to just use the gh-pages branch to compile LiveSplit One, because setting up emscripten is just really annoying. So pushing for the native wasm target makes a ton of sense. It also should improve LiveSplit One's CPU utilization a bit (turning React into the bottleneck again). So to push this further, we are really just blocked by chrono not really working out for us. We just can't disable the |
Here's the current state of native WebAssembly compilation. Everything is working except:
The text was updated successfully, but these errors were encountered: