The service was grown to over 60 million users back in ~2012 and got aquired by Autodesk. After some years most, if not all people working with the product was reassigned and or left. Still with millions of weekly users but no one that cared.
Autodesk sold it for near to nothing and the new owners contacted me (org founder) and asked me if I wanted to get involved somehow. So we build a new product from scratch since the original app was 100% Flash and we are just month away from a completely browser block :)
it'd be interesting to know about the tech behind this rewrite. E.g., what language/stack, how did you do it (or any frameworks of interest used), and what, if any, did you learn from the flash version that helped in this rewrite?
Its 99% Typescript and we don't use any premade js frameworks, everything was written from scratch (except for some font loader and zip), ui, rendering, webgl filters etc etc.
All the knowledge of how Photo Editing works came out of building the original products back in the day, there is more information about the field today to be found written online but much is still secrets kept at a few companies.
The browsers is really a shitty environment to be writing this kind of apps in, performances is a struggle in every step :)
I’ve spent years building Flash and Flex apps. Some really complex ones. Adobe had this big bets in RIAs (Rich Internet Applications). Turns out RIAs are simply SPA (Single Page Applications) now.
Typescript is really nice and close to Actionscript3. I’m glad Flash died.
The new open ecosystem with tc39 and wc3 is pretty awesome.
I’m curious if you can share some of the deep knowledge of photo editing you’ve uncovered - if not in explicit detail, what are some of the general areas where public knowledge lags behind state of the art?
I've used pixlr a few times those last few weeks as I was looking for an image editing tool that was more powerful than paint and didn't want to install more software on my PC(I think I also tried Photopea.com, but I wasn't as successful with it). It's been working very well, I finished the handful of photomontage I wanted to do, but I'm annoyed with how the tools' config reset back to its default configuration each time I switch to another tool. Still thank you for your work.
Hey Ola, I was at Autodesk Toronto around the time you were acquired and remember meeting you and your brother. I always appreciated how Pixlr solved a common problem (photo editing) really really well. Congrats on the rewrite.
Just wanted to say thank you for Pixlr, I was able to integrate it into our SaaS product and during my demo's it was a real WOW feature. Really appreciate it. We moved to a JS based image editor a few years ago when Pixlr started to get ad injections :(
Great product. One of my original fave hosted tools. I still use it. Yeah, Flash makes my cringe, but it still works. I'm looking forward to the new post-Flash version.
Yea until 100% RIP. But a couple of weeks ago ppl with flash activated get a big warning in chrome and google is penalizing flash in search etc. We are cutting it close.
Pixlr was (well, still is) a flash-based webapp that allows you to edit images in your browsers, and apparently had ~60 Million users back in 2012. It was sold to Autodesk, they didn't do much with it. Then Autodesk sold it to new owners, who invited the original founder to come and work on it, and as a result, this canvas/WebGL version was launched.
Is all of Photopea static besides things have to do with the account management? How do you go about hosting the site? I'm always curious to hear about these things from people who obviously know what they're doing.
Yes, Photopea is only one HTML, one CSS and many JS files. It is about 1.5 MB in total. I pay 40 USD a year for the hosting + 12 USD a year for the .com domain.
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)
Hi, thanks! I think the JS that I write is quite efficient and I don't expect the WASM version of the same features to be faster. But I do plan to write something in WASM and see for myself (you don't have to write in C, you can write WAST and convert it to WASM :D).
I do everything with Javascript. I never liked using native tools / compilers for programming (there are too many of them with too complex configurations). I use only a text editor and a browser for development :)
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.
Just noticed this comment after asking about WebAssembly elsewhere.
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...)
Can anybody name a successful autodesk acquisition? Their record seems quite embarrassing, filled with lots of acquisitions of unrelated tech for inflated prices that they ultimately shut down.
(No offense meant to the companies being acquired, they’re usually great. Autodesk is the one who seems to screw everything up.)
Something that many keep forgeting with their Oracle hate, is that Oracle has been part of the Java eco-system since the early days.
They did the NC Java station alongside Sun, were the first RDMS to support Java stored procedures, ported their installers and GUI tooling to Java, created their own JVM, later bought BEA, and created their own JEE implementation, among other Java frameworks.
Didn't they get rid of everything that didn't bring profit like JEE and NetBeans? The only part of Java that Oracle cares about is paid(supported)LTS versions, as there is no free LTS version anymore, with new quick release schedule. Well, that was the idea, some companies like Amazon ( https://aws.amazon.com/corretto/ ) want to backport fixes.
Their acquisition of Alias in 2006 was good, wasn’t it? That’s how Autodesk ended up as the owners of Maya, MotionBuilder, the FBX file format and a few other things.
Far out. A javascript photo editor running in a browser that feels faster than a native application like the Gimp. What an extraordinary achievement.
But it's not just the underlying speed. It's GUI interface design is simply beautiful. It's also intuitive, and discoverable. God how I wish other young designers would follow this example.
I suspect you are going to struggle commercially against "free" from the likes of Gimp unless you can survive on advertising revenue, but you've done well so far - bought out, run into the ground, sold back for pennies. It doesn't get much better than that. Given the quality of this product who knows, it may happen again.
I wish you and your product the best of luck - you deserve it.
I'm the founder of Polarr , https://photoeditor.polarr.co , if anyone wants to hack Canvas/WebGL based photo editor with a full team of Canvas/WebGL hackers, DM me!
Is there a good vector graphic version of this that folks might recommend? I'm thinking in particular of when you need to do some quick work on (data-related) graphs.
I forgot about Pixlr. I have many fond memories of making bad pixel art on it. It really was a step above all the other photo-editing webapps available at the time.
Editor looks great, very performant! Is there a way to integrate this in an existing webapp? E.g. open pixlr in a new window, do some edits, get the asset back?
Thanks! Yes it support the same api as the old ones, will update the site with more info when we leave beta in January. Simple load and post with the image asset.
> I am continually stunned at how little most developers know of what browsers are capable of.
I guess it's because developers don't always need to know everything.
The browser platform has turned native computational capabilities into a "hodge podge" of functionalities that a developer needs to pick from, so programming becomes more like shopping than like building things. Not every developer likes that mindset.
Really? the only place you wouldn't find that is in Assembly language on baremetal. Even C has platform libraries and system calls. I haven't seen a more dithered and inconsistent "hodge podge" than when trying to get something as simple as a timer working consistently across all the Unix-likes.
Browsers are just a platform like any other, you work with the platform capabilities the OS or platform gives you. what alternative do you think there is?
I’d guess the vast majority of web developers never use WebGL or Canvas directly. The alpha compositing we are talking about here is one of those, not the native compositing, because you wouldn’t use native compositing for image editing.
I would be very surprised if there were ever a version of CANVAS or WEBGL that didn't have alpha compositing. Sounds like the product of an extremely disparaging imagination.
What’s with all the negativity? I didn’t remotely suggest that WebGL or canvas ever lacked compositing, so I’m pretty confused by your response and where the attempted insult came from, or why. Maybe you’ve misunderstood. Browsers can composite elements without using WebGL or canvas, so sure most devs should know that. And, turns out they do. But most devs never need to interact directly with canvas or WebGL, so why would they know about the specific compositing modes? Most of the small number of people who do use WebGL or Canvas have never used any of the other Porter-Duff compositing modes other than “over”, and most of them have never used premultiplied alpha. It seems like no surprise at all that most people don’t know the minutiae and trivialities of what browsers can do using APIs that the majority of devs don’t use. To flip that around, there are plenty of WebGL devs who know compositing modes and yet barely know anything about browser networking, security, and caching features.
It's been better part of a year for two people team (me and my brother) to build this product. We released one product first we called x with a subset of features to get code out the door.
@mods: Perhaps rename the submission to "Pixlr founder returns after 8 years to rewrite web-based photo editor interface in canvas/WebGL" to avoid confusion.
I replaced "photoshop" with "photo editor" above. I don't see anything wrong with the title otherwise. The project creator wrote it, so it isn't editorializing.
This was one of the few times I was genuinely confused by a link on HN. I didn’t realize there was an author exception to the title rules and I’m not sure there should be.
Its not the end of the world but one of the things I like best about HN is trustworthy titles. This erodes that.
I don't see what's untrustworthy about the title here. If it were misleading we'd change it, but it doesn't seem misleading to me.
It's important that HN's front page not be completely predictable, so we allow variations sometimes. The rules here are called guidelines for that reason. HN is a spirit of the law place, not a letter of the law place, and the spirit is curiosity.
I don’t think its misleading in a malicious way. But it is misleading in the sense that the title did not at all describe the ultimate content. I would not have clicked if I knew where it lead. The confused comments here show I'm not the only one.
The actual story behind this is quite interesting. I wish there was a blog post with more details. Perhaps if they were forced to use proper titles we might have got that.
I don’t argue with your authority to vary the rules. I just wanted to provide feedback.
Appreciated! And you make a great point that a blog post with the story would be better. At least the author did include a bit of that in the thread here.
I think the only title that would satisfy site guidelines is the name of the app. They should have written a blog post with the story if they wanted to use this title.
Someone did; that someone is Adobe. Adobe Animate (previously known as Flash) can export JS code that uses a canvas to draw the animation. It has been this way for years.
Autodesk sold it for near to nothing and the new owners contacted me (org founder) and asked me if I wanted to get involved somehow. So we build a new product from scratch since the original app was 100% Flash and we are just month away from a completely browser block :)