Please switch your approach ASAP or you will be beaten by a web-based app that does this exact thing, someone else will be the Figma to your Sketch.
This specific use-case doesn't require the large amount of resources that would necessitate a desktop app.
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.
I'm asking because AFAIK unlike Windows with Direct2D, Linux doesn't have GPU-targeted vector graphics libraries. I have once made my own one when I needed something similar: https://github.com/Const-me/Vrmac#vector-graphics-engine
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, that’s what I thought. The library I have linked does the same thing. Only it’s either D3D12, or GLES 3.1 underneath.
You can modify the vertices on the CPU, update the tessellation points and update those to the GPU. Get 60fps should be possible even when updating 1Ks of vertices (probably more) per second. Do this for whatever changed using dirty lists or something so you do not update everything to the GPU on each frame. This should be relatively fast if you using ArrayBuffers.
100% this can be done in JavaScript in a very fast fashion. It may only seem like it can not be done if you are doing JS poorly. Maybe people make the mistake of not using ArrayBuffers for everything and that makes it slow. The main limitation in JS is the lack of really great multithreading, but I do not think you need it here.
If you want ultimate speed use WASM for the CPU-based updating of your geometry structures.
Anyhow, you are mistaken in your current beliefs and it will hurt you going forward.
The GPU’s hardware-implemented tessellation is (a) not compatible enough. It’s OK on Windows because Microsoft requires them for GPU vendors to declare the support of Direct3D 11. On the rest of the platforms, support across GPU vendors varies. And (b) doesn’t help much for 2D vector graphics. The hardware tessellation can be good for terrain, trees, or other triangle meshes in 3D space. Doesn’t help much for these Bezier curves/elliptical arcs for 2D shapes. Especially so for stroked paths.
Counter-intuitively, stroked paths are harder to render than filled ones. The offset of Bezier spline is not representable as another Bezier spline. Also, strokes have more parameters on input: line caps, join types, dashes, miter limit, etc.
> The main limitation in JS is the lack of really great multithreading
Also lack of SIMD. Also, the code in general is slow compared to C++, C# and many other statically typed languages. It’s incredibly hard to generate fast code from very dynamic languages like JS or Python, where everything is a hash map.
> I do not think you need it here.
Here’s my code which offloads CPU-bound pieces of 2D rendering to other CPU cores: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Draw/Tes... Multithreading helped a lot.
I am unsure why we are talking about GPU-based tesselation again. I said do it on the CPU in my comment you are referencing.
> Counter-intuitively, stroked paths are harder to render than filled ones.
I would if it could be rendered via a 2D SDF? Similar to how you can do resolution independent fonts/decals via SDFs... basically use a cutoff distance from stroke midline or similar.
> Also, the code in general is slow compared to C++, C# and many other statically typed languages. It’s incredibly hard to generate fast code from very dynamic languages like JS or Python, where everything is a hash map.
The above is 100% incorrect. The trick is to not use slow hashmaps and then your code is near the speed of C++. Use ArrayBuffers instead for everything. I said this in my earlier comment.
I don’t think so. For one, computing SDF is a computationally hard problem.
Another thing, SDF will result in round joins, look at these pictures for available options: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d... That particular spec is for MS Direct2D, but the rest of them offer the same features. Vector graphic formats are old and very stable. Similar story with line caps, SDF will get you round caps but sometimes you need different ones: https://docs.microsoft.com/en-us/windows/win32/api/d2d1/ne-d...
> The trick is to not use slow hashmaps
Every JavaScript object has such a slow hashmap, for the properties of that object.
> and then your code is near the speed of C++
JavaScript can only approach the speed of C++ for I/O bound things. For crunching numbers on CPU, the difference is rather large. Here’s some benchmark across many programming languages: https://benchmarksgame-team.pages.debian.net/benchmarksgame/ The average difference between C++ and JavaScript is 4x, for some problems it’s almost an order of magnitude.
Two reasons.
1. It’s hard to produce fast code from dynamically typed languages. CPU instructions are typed, different data types need different instructions.
2. C++ compilers work offline. In release builds, C++ optimizer can spend more time optimizing code. JavaScript JIT simply doesn’t have time to do these optimizations.
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.
Give you can create them from any cubic curve and it gives you offsets from it.
https://www.iquilezles.org/www/articles/distfunctions2d/dist...
If you offset in both direction from a curve, you can pick a start and end threshold to fill an outline. This only gives you rounded outline strokes. If you had separable tangential versus normal SDFs you could vary your end cap types.
Now how do you handle an arbitrary set of knots/control points in one shader? That is a separate problems for which there are a bunch of solutions.
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.
But then do not target desktop. You should target tablets and the pen-based interface on them.
But otherwise I clearly agree with you. There's no reason why I would make it web-based in the first place.
Software distribution and/or installation, presumably.
But these factors mostly apply to the consumer and prosumer market segments (hence, the web triggered the 'consumerization of IT'), rather than to the professional market.