4 ms·

Really, inst there anything which comes Slug-level of capabilities and is not super expensive?

by larodi 10mo ago

coffeeaddict1 10mo ago
Vello [0] might suit you although it's not production grade yet. [0] https://github.com/linebender/vello https://github.com/linebender/vello
miguel_martin 10mo ago
Just use blend2d - it is CPU only but it is plenty fast enough. Cache the rasterization to a texture if needed. Alternatively, see blaze by the same author as this article: https://gasiulis.name/parallel-rasterization-on-cpu/ https://gasiulis.name/parallel-rasterization-on-cpu/
reallynattu 10mo ago
ThorVG might be worth a look - open source (MIT), ~150KB core, GPU backends (WebGPU, OpenGL). We are using it as official dotLottie runtimes, now a Linux Foundation project. Handles SVG, Lottie, fonts, effects. https://github.com/thorvg/thorvg/ https://github.com/thorvg/thorvg/
- coffeeaddict1 10mo ago
  In terms of performance, it's quite far from something like Blend2D or Vello though.
  - hermet 10mo ago
    Blend2D is a CPU-only rendering engine, so I don't think it's a fair comparison to ThorVG. If we're talking about CPU rendering, ThorVG is faster than Skia. (no idea about Blend2d) But at high resolutions, CPU rendering has serious limitations anyway. Blend2D is still more of an experimental project that JIT kills the compatiblity and Vello is not yet production-ready and webgpu only. No point of arguing fast today if it's not usable in real-world scenarios.
    - Asm2D 10mo ago
      How JIT kills compatibility if it's only enabled on x86 and aaarch64? You can compile Blend2D without it and it would just work. So no, it doesn't kill any compatibility - it only shows a different approach. BTW GPU-only renderers suck, and many renderers that have GPU and CPU engines suck when GPU is not available or have bugs. Strong CPU rendering performance is just necessary for any kind of library if you want true compatibility across various platforms. I have seen many many times broken rendering on GPU without any ability to switch to CPU. And the biggest problem is that more exotic HW you run it on, less chance that somebody would be able to fix it (talking about GPUs).
hermet 10mo ago
Check this out: https://thorvg-perf-test.vercel.app/ https://thorvg-perf-test.vercel.app/ https://www.youtube.com/watch?v=jdnnzmtHy9k https://www.youtube.com/watch?v=jdnnzmtHy9k

Really, inst there anything which comes Slug-level of capabilities and is not super expensive?

by larodi 10mo ago

Really, inst there anything which comes Slug-level of capabilities and is not super expensive?

Vello [0] might suit you although it's not production grade yet. [0] https://github.com/linebender/vello https://github.com/linebender/vello

miguel_martin 10mo ago

Just use blend2d - it is CPU only but it is plenty fast enough. Cache the rasterization to a texture if needed. Alternatively, see blaze by the same author as this article: https://gasiulis.name/parallel-rasterization-on-cpu/ https://gasiulis.name/parallel-rasterization-on-cpu/

reallynattu 10mo ago

ThorVG might be worth a look - open source (MIT), ~150KB core, GPU backends (WebGPU, OpenGL). We are using it as official dotLottie runtimes, now a Linux Foundation project. Handles SVG, Lottie, fonts, effects. https://github.com/thorvg/thorvg/ https://github.com/thorvg/thorvg/

coffeeaddict1 10mo ago
In terms of performance, it's quite far from something like Blend2D or Vello though.
- hermet 10mo ago
  Blend2D is a CPU-only rendering engine, so I don't think it's a fair comparison to ThorVG. If we're talking about CPU rendering, ThorVG is faster than Skia. (no idea about Blend2d) But at high resolutions, CPU rendering has serious limitations anyway. Blend2D is still more of an experimental project that JIT kills the compatiblity and Vello is not yet production-ready and webgpu only. No point of arguing fast today if it's not usable in real-world scenarios.
  - Asm2D 10mo ago
    How JIT kills compatibility if it's only enabled on x86 and aaarch64? You can compile Blend2D without it and it would just work. So no, it doesn't kill any compatibility - it only shows a different approach. BTW GPU-only renderers suck, and many renderers that have GPU and CPU engines suck when GPU is not available or have bugs. Strong CPU rendering performance is just necessary for any kind of library if you want true compatibility across various platforms. I have seen many many times broken rendering on GPU without any ability to switch to CPU. And the biggest problem is that more exotic HW you run it on, less chance that somebody would be able to fix it (talking about GPUs).

hermet 10mo ago

Check this out: https://thorvg-perf-test.vercel.app/ https://thorvg-perf-test.vercel.app/ https://www.youtube.com/watch?v=jdnnzmtHy9k https://www.youtube.com/watch?v=jdnnzmtHy9k