Hi, I am the creator of https://www.Photopea.com and I am a bit sad, that you did not start to work on it earlier. Wish you good luck! :)
Actually, it is the 19th most frequent format of files opened in Photopea :) https://twitter.com/photopeacom/status/1172183966125871105
Jaw dropped when i realised the "screenshot" of the editor is actually the editor. On my phone!
Of course I've used Pixlr and i love it bur will definitely try PeaApp more
Ivan and Ola deserve a huge thank you for releasing these tools!
I gave a talk about it: https://www.youtube.com/watch?v=IZmaeC_Ma5A
Have you tried moving particularly hot portions of code to WebAssembly yet?
Obviously in Photopea's case this would generally require rewriting portions of the code in C/C++/Rust, and potentially doing a few iterations of looking at the generated WASM and tweaking the input to produce the best (maintainable) results... so a bit of a long-term project :)
Whenever you get to this, I'm sure a lot of people would appreciate a benchmark post with speedup percentages etc.
And WASM is so new that maybe sharing some of the approaches you used, the JS you started with, and the C/C++/Rust/etc you ended up with, might also attract folks looking for assistance with their own image-processing-related projects. (This being said... translation: I, like lots of others, am extremely interested in the bits of code that make Photopea so efficient, which you worked hard to perfect and have every right to not share :D)
I open-sourced many parts of Photopea: https://github.com/photopea?tab=repositories .
WASM builds of two C libraries are used in Photopea: Harfbuzz (177 kB) and Fribidi (32 kB). But their authors were kind enough to give me WASM files directly, so I did not have to compile anything.
Wow, that's amazing.
I did some headscratching with WebAssembly a little while back while figuring out what approach to take for a small thing I wanted to make reasonably cross-platform. My terribly nonscientific back-of-the-envelope benchmark was to time reading/writing an array. Initially JavaScript won squarely over WASM, but then I realized I wasn't using -O3 (woops) and the WebAssembly got about 1.75x faster than it appeared my JS code ever would.
In my very limited experience the most significant difference at the end of the day seems to be that the source language isn't JavaScript. All tooling seems to have grown some element of "????" sadly, and all languages bring their own warts. Once I figured out a working [webassembly generation] workflow, it felt pretty solid, like it wasn't about to fall over too easily. Clang support seems to be just about perfect at this point, if you haven't tried it within the past few months.
My personal first medium/long-term step will be to get a good grip on reading WebAssembly S-expressions, so I can help keep the loop as closed as possible in terms of understanding what my source is generating. (And maybe follow the occasional reverse engineering white rabbit.)
Next will be conquering my love of interpreted languages that don't have a compile step (let alone a long one ;) ), haha. JavaScript indeed can't be beat for rapid iteration! (Particularly if you use live-reload in testing...)