5 ms·

WebDSP Media Library and WebAssembly Video Editor Demo

85 points by indescions_2017 9y ago

slimsag 9y ago
This is a great example of how much faster WebAssembly can be for some applications! On the topic of video editing, though, this will be even faster still once WebAssembly supports threads[1] [1] https://github.com/WebAssembly/design/issues/1073 https://github.com/WebAssembly/design/issues/1073
- slimsag 9y ago
  Also, one reason I am excited about WebAssembly is because it is a low-level target for compiled languages that is also cross-platform. I know others exist, too, but I think this being the web will cause more and more people to get into writing compiled languages :)
- chrismorgan 9y ago
  My observation on their demo, with 64-bit Firefox Nightly for Windows on a Surface Book (i7-6600U, using integrated graphics): • For most of the filters, WebAssembly averages 10–40% slower than JavaScript; • For some of the filters, WebAssembly averages −10%–40% faster than JavaScript; • For Super Edge, WebAssembly averages 10–20× faster than JavaScript; • Beards look even cooler than normal with Super Edge (though I wouldn’t want my beard to look like that in real life).
  - _Codemonkeyism 9y ago
    What I always found interesting is the (psychological) asymmetry +50% means 50% slower -50% means twice as fast (or with stocks, going down 50% means you lose half of your money, going back to the original value means you double your investment (for new investors) which I think basically drives stock market investments)
- markdog12 9y ago
  And SIMD: https://github.com/WebAssembly/design/issues/1075 https://github.com/WebAssembly/design/issues/1075
IvanK_net 9y ago
Note, that these simple image filters could be made with WebGL and run like 50 times faster than WASM or JS. Also, you can not just say that "a language is faster than another language". In current modern web browsers, you can write JS programs, that are equally perfromant, as the WASM program (WASM would be at most 10 - 20 percent faster). So if you see JS being slower in this case, maybe it just was not written properly. So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance.
- trgv 9y ago
  > So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance. That may be true for now, but there are other advantages that have at least something to do with performance. For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed. I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice. In general, it will be easier to add new features to wasm compared to JavaScript. Presumably this means features like threads will land in wasm much sooner than in JavaScript, but we'll see.
  - batmansmk 9y ago
    > For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed True, but as long as you have space for cache, it only goes faster once. Wasm is also loaded by JS itself and of limited usage right. I think the first comment is actually accurate about the state of wasm. It only brings value to people compiling from C/C++ to the web. It is not a technology of the future, but a retrofit for the past.
  - fenwick67 9y ago
    > I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice. When it's a big transpiled application (ex: games, the "Run Windows 95 in Your Browser" demos), it has a real impact since the binary is just so large. This is probably the biggest jump between asm.js and WebAssembly.

This is a great example of how much faster WebAssembly can be for some applications! On the topic of video editing, though, this will be even faster still once WebAssembly supports threads[1] [1] https://github.com/WebAssembly/design/issues/1073 https://github.com/WebAssembly/design/issues/1073

slimsag 9y ago
Also, one reason I am excited about WebAssembly is because it is a low-level target for compiled languages that is also cross-platform. I know others exist, too, but I think this being the web will cause more and more people to get into writing compiled languages :)
chrismorgan 9y ago
My observation on their demo, with 64-bit Firefox Nightly for Windows on a Surface Book (i7-6600U, using integrated graphics): • For most of the filters, WebAssembly averages 10–40% slower than JavaScript; • For some of the filters, WebAssembly averages −10%–40% faster than JavaScript; • For Super Edge, WebAssembly averages 10–20× faster than JavaScript; • Beards look even cooler than normal with Super Edge (though I wouldn’t want my beard to look like that in real life).
- _Codemonkeyism 9y ago
  What I always found interesting is the (psychological) asymmetry +50% means 50% slower -50% means twice as fast (or with stocks, going down 50% means you lose half of your money, going back to the original value means you double your investment (for new investors) which I think basically drives stock market investments)
markdog12 9y ago
And SIMD: https://github.com/WebAssembly/design/issues/1075 https://github.com/WebAssembly/design/issues/1075

IvanK_net 9y ago

Note, that these simple image filters could be made with WebGL and run like 50 times faster than WASM or JS. Also, you can not just say that "a language is faster than another language". In current modern web browsers, you can write JS programs, that are equally perfromant, as the WASM program (WASM would be at most 10 - 20 percent faster). So if you see JS being slower in this case, maybe it just was not written properly. So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance.

trgv 9y ago
> So, in my opinion, the true benefit of WASM is the ability to compile into it from other low-level languages, but not the preformance. That may be true for now, but there are other advantages that have at least something to do with performance. For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed. I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice. In general, it will be easier to add new features to wasm compared to JavaScript. Presumably this means features like threads will land in wasm much sooner than in JavaScript, but we'll see.
- batmansmk 9y ago
  > For one thing, wasm bytecode can be decoded much faster than JavaScript can be parsed True, but as long as you have space for cache, it only goes faster once. Wasm is also loaded by JS itself and of limited usage right. I think the first comment is actually accurate about the state of wasm. It only brings value to people compiling from C/C++ to the web. It is not a technology of the future, but a retrofit for the past.
- fenwick67 9y ago
  > I'm not really aware of situations when parsing speed is an issue, but I imagine there are situations where this is nice. When it's a big transpiled application (ex: games, the "Run Windows 95 in Your Browser" demos), it has a real impact since the binary is just so large. This is probably the biggest jump between asm.js and WebAssembly.