2020-12-09 02:21 阅读 1

WASM experience?

Does anyone have any experience in compiling this to WASM please?


  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

5条回答 默认 最新

  • weixin_39669204 weixin_39669204 2020-12-09 02:21

    With the libz_sys and rayon dependencies I don't think it would build to wasm. You'd also need a threading API to make use of it, and a supporting browser or non-browser runtime, and none of that stuff is very standardized at this point.

    点赞 评论 复制链接分享
  • weixin_39947396 weixin_39947396 2020-12-09 02:21

    Hey, wasm threads just landed https://hacks.mozilla.org/2020/07/firefox-79/ btw, libz_sys might be replaced by miniz_oxide to get wasm support

    点赞 评论 复制链接分享
  • weixin_39669204 weixin_39669204 2020-12-09 02:21

    Wasm threading still hasn't landed in Safari, but is in Chrome on most platforms (not Android) and now in Firefox, as long as the web page opts in to certain HTTP headers.

    It looks like wasm-bindgen now supports threads and can build rayon, so that's a good sign!

    I think the stickiest point will be the C code in libz_sys if there's not suitable helper code for building C to wasm somehow.

    You'll also lose some performance over native code in the filters, which are SIMD-optimized. Wasm's SIMD extension is still experimental and not widely enabled. But with the threading it may still be a win over asking the browser to compress an image.

    点赞 评论 复制链接分享
  • weixin_39669204 weixin_39669204 2020-12-09 02:21

    A while ago I did a quick test of using miniz_oxide: https://github.com/brion/mtpng/commits/miniz-oxide

    The performance was not great, but that may be in part because there's no way to set the dictionary at the beginning of compression, so to prime each section we have to re-compress the last 32 KiB of the last section and then flush the data and throw it away before putting in the actual data for this chunk. miniz_oxide just doesn't seem to expose an interface to do that efficiently (or didn't at the time).

    That could be fixed but would require coordinating a patch with miniz_oxide I guess?

    (the hack does set it to 'no compression' so it's relatively cheap but maybe not ..... clean :D)

    (anyway there's perf issues remaining compared to zlib, which could easily outweigh multithreading in many cases vs letting the browser do it with libpng)

    点赞 评论 复制链接分享
  • weixin_39947396 weixin_39947396 2020-12-09 02:21

    I don't know if this is helpful, but pcwalton has written a multi-threaded png decoder before: https://github.com/pcwalton/parng

    And for the perf problem, I'm thinking that supporting WASM is already a big step forward. It could even be gated by cfg(target_arch) so it will not affect other targets

    点赞 评论 复制链接分享