WebAssembly #21
Comments
|
Yes please. This is on my radar, but I don't have any time to work on it soon. Dependencies right now are glium, glutin, winit. winit got web support recently. The OpenGL usage is contained in the ezgui crate and doesn't use anything fancier than scissor test and texture arrays. |
|
Info on the winit support: https://users.rust-lang.org/t/winit-0-20-and-web-support/36155 |
|
Starting experiments with webgl at https://github.com/dabreegster/rust_wasm_gui_test |
|
This is actually getting quite close: https://github.com/dabreegster/abstreet/tree/wasm
As always, I'd love help with this! |
|
|
|
Seems quite laggy? |
|
Oh yeah, definitely. I haven't tried in release mode yet, but I bet that'll help. Lots of other bugs to work through before this is anywhere near ready. Probably the hardest piece will be getting some variation of text rendering through usvg without a dependency on harfbuzz. |
|
Currently waiting on linebender/resvg#229 |
|
Hi, I want to let you know that |
|
I originally chose stdweb over web-sys many months ago, because it wasn't clear which one was used more, and following the stdweb example seemed slightly easier at the time. I don't think there are any blockers for us switching to web-sys, and we want to use the better maintained option. @michaelkirk did some deep dives into the two recently to fix some bugs and has better context. Should we just migrate to web-sys now? |
|
Yep, I think migrating to web-sys makes sense. AFAIK the most substantial piece of work will be writing the boilerplate to replace Do you want me to pursue it @dabreegster? |
I have no understanding of this stuff and want to remedy that, so I'll take a crack at it, if that's OK @alvinhochun, we can pin to particular git commits of winit, so don't let us block any stdweb cleanup. Thanks for checking in! |
|
Be my guest! |
cd game; wasm-pack build -- --no-default-features --features wasm
cd game; wasm-pack build -- --no-default-features --features wasm
Just a few changes to make usvg not depend on Rustybuzz (which is still in the middle of becoming a pure Rust library). It probably only works with English fonts, but for the moment, it moves us forward.
When I added web support in February, it was easier to get started with stdweb, since it has the nice cargo web tool. However, stdweb is unmaintained, winit is deprecating support for it, and the next steps for web (downloading maps dynamically) have better support for web-sys. With Alvin's guidance, I got https://github.com/dabreegster/minimal_websys_winit_glow_demo working first. This PR cuts A/B Street over too. I tested abst and the widgetry demo in both native and web. The only major regression from stdweb is the canvas placement and size. I attempted some fixes, but at this point, I'll leave it as a smaller followup instead.
When I added web support in February, it was easier to get started with stdweb, since it has the nice cargo web tool. However, stdweb is unmaintained, winit is deprecating support for it, and the next steps for web (downloading maps dynamically) have better support for web-sys. With Alvin's guidance, I got https://github.com/dabreegster/minimal_websys_winit_glow_demo working first. This PR cuts A/B Street over too. I tested abst and the widgetry demo in both native and web. The only major regression from stdweb is the canvas placement and size. I attempted some fixes, but at this point, I'll leave it as a smaller followup instead.
… surface area, making it easier to add more web support for #21.
When I added web support in February, it was easier to get started with stdweb, since it has the nice cargo web tool. However, stdweb is unmaintained, winit is deprecating support for it, and the next steps for web (downloading maps dynamically) have better support for web-sys. With Alvin's guidance, I got https://github.com/dabreegster/minimal_websys_winit_glow_demo working first. This PR cuts A/B Street over too. I tested abst and the widgetry demo in both native and web. The only major regression from stdweb is the canvas placement and size. I attempted some fixes, but at this point, I'll leave it as a smaller followup instead.
When I added web support in February, it was easier to get started with stdweb, since it has the nice cargo web tool. However, stdweb is unmaintained, winit is deprecating support for it, and the next steps for web (downloading maps dynamically) have better support for web-sys. With Alvin's guidance, I got https://github.com/dabreegster/minimal_websys_winit_glow_demo working first. This PR cuts A/B Street over too. I tested abst and the widgetry demo in both native and web. The only major regression from stdweb is the canvas placement and size. I attempted some fixes, but at this point, I'll leave it as a smaller followup instead.
When I added web support in February, it was easier to get started with stdweb, since it has the nice cargo web tool. However, stdweb is unmaintained, winit is deprecating support for it, and the next steps for web (downloading maps dynamically) have better support for web-sys. With Alvin's guidance, I got https://github.com/dabreegster/minimal_websys_winit_glow_demo working first. This PR cuts A/B Street over too. I tested abst and the widgetry demo in both native and web. The only major regression from stdweb is the canvas placement and size. I attempted some fixes, but at this point, I'll leave it as a smaller followup instead.
This is a very strange, specializd approach; it's unclear how it'll generalize to reading scenarios and prebaked results. Ideally we could call abstutil::read_binary as we currently do and somehow hide this async trickery underneath, but I'm not sure how yet. In the meantime, this moves us forward with the hack well-contained. Next steps for web: stop bundling in all of data/system in the .wasm, now that we can load from HTTP.
This is a very strange, specializd approach; it's unclear how it'll generalize to reading scenarios and prebaked results. Ideally we could call abstutil::read_binary as we currently do and somehow hide this async trickery underneath, but I'm not sure how yet. In the meantime, this moves us forward with the hack well-contained. Next steps for web: stop bundling in all of data/system in the .wasm, now that we can load from HTTP.
This is a very strange, specializd approach; it's unclear how it'll generalize to reading scenarios and prebaked results. Ideally we could call abstutil::read_binary as we currently do and somehow hide this async trickery underneath, but I'm not sure how yet. In the meantime, this moves us forward with the hack well-contained. Next steps for web: stop bundling in all of data/system in the .wasm, now that we can load from HTTP.
#364) * On the web, load different maps by making asynchronous HTTP calls. #21 This is a very strange, specializd approach; it's unclear how it'll generalize to reading scenarios and prebaked results. Ideally we could call abstutil::read_binary as we currently do and somehow hide this async trickery underneath, but I'm not sure how yet. In the meantime, this moves us forward with the hack well-contained. Next steps for web: stop bundling in all of data/system in the .wasm, now that we can load from HTTP.
This has the effect of breaking the city loader, because it lists bundled files to discover other cities. Going to rethink that next.
|
http://abstreet.s3-website.us-east-2.amazonaws.com/ I'm declaring victory. Many things are broken compared to the native version (saving your edits, partially transparent colors), but enough works to try it out! If you find other issues with web specifically, please file more bugs. Thanks! |
WebGL?
The text was updated successfully, but these errors were encountered: