borisdalstein

Very interesting read, thanks for sharing!

Wow, your library actually looks impressive! Yeah, I'm pretty much implementing all the same things.

Thanks a lot Const-me for all your very accurate responses! I basically have nothing more to add.

Oh, and indeed, SDF is just completely irrelevant to the problem at hand here.

I would kindly suggest ninetenfour to avoid making bold statements without more domain experience. JS is great for many things. It's just not the tool for the job here.

I will also target iPads and Android tablets as native apps, yes. But most professional users use a powerful desktop computer with a Wacom Intuos or Cintiq. Some professional work requires hundreds of layers, and in the context of animation, you're not going to make the next Studio Ghibli animation on an iPad. You need your 64GBs or RAM.

Playing devil's advocate, I'd argue that it does make development much faster, and portability much easier. This is important.

But otherwise I clearly agree with you. There's no reason why I would make it web-based in the first place.

Thanks a lot! Getting the code for Expression could be interesting, although the code is so old, I wonder how useful it would be. Especially modern C++ has changed a lot, sometimes it's nice to start with a clean slate.

I'm using 3D graphics APIs, OpenGL on Linux currently, but Vulkan will be an option later. I'm converting everything to triangles on the CPU and send to OpenGL.

Note that the animation app actually needs to show 3D graphics for a 2D+time visualization which is part of the innovation in my research.

Thanks for all the advice, I know it is well-intended, but unfortunately this late in the project there is nothing that could change my mind anyway. It's too late.

But even if I had to start from scratch, I would still use C++. It is the most-used language in this field for rational reasons, not just for mistaken beliefs. Multi-threading is important, supporting custom pen tablets hardware is important, accessing Metal and Direct3D graphics API is important, being able to use the core as a shared library for command-line tools is important, being able to not crash when another tab makes the browser crash is important (okay, for this I could use electron). Being able to embed a Python interpreter is important (yes, it has to be Python it's a design decision). And we're not talking 1Ks vertices, but millions.

Again, AAA games are not developed in Javascript for a reason. Professional productivity graphics application have the same requirements than AAA games.

It is indeed strange, the technology hasn't progressed much, especially compared to 3D modeling/animation! I hypothesize that the stagnation is because researchers in computer science are more naturally drawn to 3D since the problems seem more fun and challenging, and they may not realize there are still things to improve in the 2D world.

Wow, this is cool, I had heard of Expression but didn't the whole backstory. I will definitely have to check it out.

And indeed I have a lot of catching up to do feature-wise :) VGC Illustration won't be able to be as feature-complete as Illustrator for a long time, but hopefully the killer features and better drawing experience will make up for it.

Thanks for the comment, I'm the developer of the app! Having it run in a browser would clearly be convenient, but unfortunately Javascript is really too slow. I even wish C++ was faster.

Rendering the vector paths requires the same type of heavy computation as a modern AAA game, and we don't see AAA games implemented in Javascript for good reasons. The paths need to be tessellated, sent to the GPU, then the different layers need to be composited, and all of this takes computational resources.

In addition, unlike Figma where the vector paths are created by manipulating control points, in VGC Illustration it is expected that the paths can be created by sketching them, hand-drawn. This requires extremely low latency and high FPS for the drawing experience to be any good. There's already quite a bit of lag between the stylus and the shown stroke even in Photoshop, you don't wan't this to be any worse :)

I hope this makes sense.