Skip to content
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

Loading a jpg image causes a panic in WASM #508

Closed
francesco-cattoglio opened this issue Jun 24, 2019 · 1 comment · Fixed by #558
Closed

Loading a jpg image causes a panic in WASM #508

francesco-cattoglio opened this issue Jun 24, 2019 · 1 comment · Fixed by #558
Labels
bug Some API breaks the contract it establishes platform-wasm WASM-specific code changes or bugs subsystem-util

Comments

@francesco-cattoglio
Copy link
Contributor

Describe the bug
Loading a jpg file in wasm build causes a panic.

To Reproduce
Run the image.rs example, but instead of loading a png, try loading a jpg (such as the attached one) and run with cargo web start
image
Running the example in native build will work with no issues instead.

Environment and versions (please complete the following information):

  • Environment: Ubuntu + Firefox, but it should not matter
  • Rust compiler version: Rust stable 1.35
  • Quicksilver version: latest

Notes:
I tracked down the origin of the problem, and it lies in the jpeg-decoder package: by default it uses rayon, but rayon is not fully supported by wasm yet: it does compile, but it panics on usage. See also image-rs/image#879 and image-rs/image#724

It should be really easy to fix, just by modifying the Cargo.toml. However when I tried playing around with my local quicksilver version, no matter what changes I did to Cargo.toml, they were ignored, so I was unable to create a fix... sorry, I am still a rust noob! 😛
OTOH, if I use my fork of jpeg-decoder and manually disable the code path using rayon, everything works, so I am 100% confident: usage of rayon in the image/jpeg-decoder package is the source of the panic.

@ryanisaacg
Copy link
Owner

That is indeed a problem! I guess the way to fix that is to disable Rayon in image on web targets. At some point this week I'll try to take a look and get a fix out for that.

@ryanisaacg ryanisaacg added bug Some API breaks the contract it establishes platform-wasm WASM-specific code changes or bugs subsystem-util labels Jun 25, 2019
ryanisaacg added a commit that referenced this issue Jan 8, 2020
Also update image to 0.22 from 0.21, and remove the jpeg rayon feature.
This may take some perf hit on desktop, but it removes unnecessary
complexity and makes jpeg work on web.

Now that image isn't depended on by winit, there's no other crate
toggling on default features accidentally. Removing the rayon feature
actually removes it!

Resolves #508
ryanisaacg added a commit that referenced this issue Jan 8, 2020
Also update image to 0.22 from 0.21, and remove the jpeg rayon feature.
This may take some perf hit on desktop, but it removes unnecessary
complexity and makes jpeg work on web.

Now that image isn't depended on by winit, there's no other crate
toggling on default features accidentally. Removing the rayon feature
actually removes it!

Resolves #508
leod pushed a commit to leod/quicksilver that referenced this issue Jun 3, 2023
Also update image to 0.22 from 0.21, and remove the jpeg rayon feature.
This may take some perf hit on desktop, but it removes unnecessary
complexity and makes jpeg work on web.

Now that image isn't depended on by winit, there's no other crate
toggling on default features accidentally. Removing the rayon feature
actually removes it!

Resolves ryanisaacg#508
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Some API breaks the contract it establishes platform-wasm WASM-specific code changes or bugs subsystem-util
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants