6 ms·

> I wish there was a nice and small vector graphics library with GPU acceleration. I'm personally skeptical about GPU acceleration being the answer to 2D rende

> I wish there was a nice and small vector graphics library with GPU acceleration. I'm personally skeptical about GPU acceleration being the answer to 2D rendering for various reasons. I'm looking forward to Blend2D < https://blend2d.com/ https://blend2d.com/ > which is JIT based maturing and being the preferred solution.

gigatexal 3y ago
What happened to Cairo the 2d graphics tool?
- jb1991 3y ago
  Nothing happened to it. It’s just slow.
  - yetihehe 3y ago
    It's not that slow, I was amazed by performance when I first used it, but maybe other libs are even faster.
    - mort96 3y ago
      It's perfectly decent for a CPU renderer, CPU rendering is just slow.
      - yetihehe 3y ago
        I had to make a map module for python desktop application , options were either embed full browser inside and use google maps, or do it myself. C module using cairo was MUCH faster and easier to achieve in 2013. So much faster I didn't have to implement some optimizations I planned because it was already running at about 50fps on average computers with ~1000 individually drawn markers on a map. Requiring any gpu for this was not possible anyway.
- gigatexal 3y ago
  Can it be GPU accelerated? (Is that even a dumb question to ask?)
  - tetromino_ 3y ago
    Cairo has only limited support for GPU acceleration and hasn't seen much development this decade. So users who care about performance have either switched away from Cairo entirely or are at least reducing its usage and are taking it out of the fast path.
    - Asm2D 3y ago
      GPU support was removed from Cairo, because it was slower than CPU rendering and nobody wanted to maintain it.
      - tetromino_ 3y ago
        Cairo's OpenGL support was removed, but I thought Cairo's X11 backend still has GPU acceleration for a few operations through XRender (depending on your video driver).
        Asm2D 3y ago
        That's true, Cairo still provides XRender backend. Not sure it's that usable though as I think nobody really focuses on improving XRender, so it's probably in the same state as Cairo itself.
- Asm2D 3y ago
  Cairo is in a maintenance-only mode. Nobody develops this library anymore and it only has a maintainer or two. Since nobody really worked on Cairo in the past 15 years it's not optimized for modern hardware. You can see some existing benchmarks here: - https://blend2d.com/performance.html Both the benchmarking tool and Blend2D are open-source projects so anyone can verify the numbers presented are indeed correct, and anyone can review/improve the backend-specific code that is used by the benchmarking tool.
  - hgs3 3y ago
    > Cairo is in a maintenance-only mode. That's too bad. Is their a successor planned or is Skia the recommended alternative?
    - Asm2D 3y ago
      I think that when it comes to 2D rendering libraries there is in general not too many options if you want to target CPU or both CPU+GPU. Targeting GPU-only is bad for users that run on a hardware where GPU doesn't perform well or is not available at all due to driver issues or just not present (like servers). If you consider libraries that offer CPU rendering there are basically: - AGG (CPU only) - Blend2D (CPU only, GPU planned, but not now) - Cairo (CPU only) - Qt's QPainter (CPU only, GPU without anti-aliasing / deprecated) - Skia (CPU + GPU) - Tiny Skia (CPU only, not focused on performance) - GPU only libs (there is many in C++ and Rust) Nobody develops AGG and Cairo anymore and Qt's QPainter hasn't really improved in the past decade (Qt Company's focus is QtQuick, which doesn't use QPainter, so they don't really care about improving the performance of QPainter). So, only 2 libraries from this list have active development - Blend2D and Skia. As an author of Blend2D I hope that it will be a go-to replacement for both AGG and Cairo users. Architecturally, Blend2D should be fine after a 1.0 release as the plan is to offer a stable ABI with 1.0 - And since Blend2D only exports C-API it should be a great choice for users who want to use every cycle and who want their code to work instead of making changes every time the dependency is updated (hello Skia). At the moment Blend2D focuses on AGG users though, because AGG is much more widespread in commercial applications due to its licensing model and extensibility. However, AGG is really slow especially when rendering to large images (like 4K) so switching from AGG to Blend2D can offer a great performance benefits while avoiding other architectural changes of the application itself. BTW Blend2D is still under active development. It started as an experiment and historically it only offered great performance on X86 platforms, but that is changing with a new JIT backend, which provides both X86 and AArch64 support and is almost ready for merge. This is good news as it will enable great performance on Apple hardware and also other AArch64 devices, basically covering 99% of the market.
- pizza234 3y ago
  Some details in the article: > There was an attempt at making Cairo support GPU rendering, which did not work particularly well due to the library being designed around stateful operation based upon the PostScript model—resulting in a convenient and familiar API, great output quality, but hard to retarget and with some particularly slow corner cases. Meanwhile, other web engines have moved more work to the GPU, including 2D rendering, where many operations are considerably faster.
fxtentacle 3y ago
According to their benchmark, multi-threaded rendering on a Ryzen 7950X will take about 1.7ms with 4 cores for drawing 1000x polygons with 40 vertices each on a 32x32 px area, which seems like a reasonable approximation for a text character on a high-DPI display. The default font size in JetBrains fits about 2500 characters onto my screen, so I'd expect a 4.25ms frame time, meaning I am capped at 235 FPS with 4 CPU cores running at full speed. I believe the best way is probably to use Blend2D for rendering glyph bitmaps and then compositing them into the full text on GPU. Sadly, CPU memory is still plenty slow compared to GPU memory and when you need to copy around 100 MB images (4K RGB float), then that quickly becomes the limiting factor.
- Asm2D 3y ago
  Text rendering is something that will get improved in the future. At the moment when you render text Blend2D queries each character from the font and then rasterizes all the edges and runs a pipeline to composite them. All these steps are super optimized (there is even a SIMD accelerated TrueType decoder, which I have successfully ported to AArch64 recently), so when you compare this approach against other libraries you still get like 4-5x performance difference in favor of Blend2D, but if you compare this method against cached glyphs Blend2D loses as it has to do much more work per glyph. So the plan is to use the existing pipeline for glyphs that are larger (let's say 30px+ vertically) and to use caching for glyphs that are smaller, but how it's gonna be cached is currently in research as I don't consider simple glyph caching in a mask a great solution (it cannot be sub-pixel positioned and it cannot be rotated - and if you want that subpixel positioned the cache would have to store each glyph several times). There is a demo application in blend2d-apps repository that can be used to compare Blend2D text rendering vs Qt, and the caching Qt does is clearly visible in this demo - when the text is smaller Qt renders it differently and characters can "jump" from one pixel to another when the font size is slightly scaled up and down, so Qt glyph caching has its limits and it's not nice when you render animated text, for example. This is a property that I consider very important so that's why I want to design something better than glyph masks that would be simple to calculate on CPU. One additional interesting property of Qt glyph caching is that once you want to render text having a size that was not cached previously, something in Qt takes 5ms to setup, which is insane... BTW one nice property of Blend2D text rendering is that when you use the multithreaded rendering context the whole text pipeline would run multithreaded as well (all the outline decoding, GSUB/GPOS processing, rasterization, etc...).
Asm2D 3y ago
Thanks! I'm doing what I can to make Blend2D even faster. It's been really exciting project to work on and I have big plans with this library.
pas 3y ago
Have you heard about Vello (written in Rust) https://www.youtube.com/watch?v=mmW_RbTyj8c&feature=youtu.be https://www.youtube.com/watch?v=mmW_RbTyj8c&feature=youtu.be ?

gigatexal 3y ago

What happened to Cairo the 2d graphics tool?

jb1991 3y ago
Nothing happened to it. It’s just slow.
- yetihehe 3y ago
  It's not that slow, I was amazed by performance when I first used it, but maybe other libs are even faster.
  - mort96 3y ago
    It's perfectly decent for a CPU renderer, CPU rendering is just slow.
    - yetihehe 3y ago
      I had to make a map module for python desktop application , options were either embed full browser inside and use google maps, or do it myself. C module using cairo was MUCH faster and easier to achieve in 2013. So much faster I didn't have to implement some optimizations I planned because it was already running at about 50fps on average computers with ~1000 individually drawn markers on a map. Requiring any gpu for this was not possible anyway.
gigatexal 3y ago
Can it be GPU accelerated? (Is that even a dumb question to ask?)
- tetromino_ 3y ago
  Cairo has only limited support for GPU acceleration and hasn't seen much development this decade. So users who care about performance have either switched away from Cairo entirely or are at least reducing its usage and are taking it out of the fast path.
  - Asm2D 3y ago
    GPU support was removed from Cairo, because it was slower than CPU rendering and nobody wanted to maintain it.
    - tetromino_ 3y ago
      Cairo's OpenGL support was removed, but I thought Cairo's X11 backend still has GPU acceleration for a few operations through XRender (depending on your video driver).
      - Asm2D 3y ago
        That's true, Cairo still provides XRender backend. Not sure it's that usable though as I think nobody really focuses on improving XRender, so it's probably in the same state as Cairo itself.
Asm2D 3y ago
Cairo is in a maintenance-only mode. Nobody develops this library anymore and it only has a maintainer or two. Since nobody really worked on Cairo in the past 15 years it's not optimized for modern hardware. You can see some existing benchmarks here: - https://blend2d.com/performance.html Both the benchmarking tool and Blend2D are open-source projects so anyone can verify the numbers presented are indeed correct, and anyone can review/improve the backend-specific code that is used by the benchmarking tool.
- hgs3 3y ago
  > Cairo is in a maintenance-only mode. That's too bad. Is their a successor planned or is Skia the recommended alternative?
  - Asm2D 3y ago
    I think that when it comes to 2D rendering libraries there is in general not too many options if you want to target CPU or both CPU+GPU. Targeting GPU-only is bad for users that run on a hardware where GPU doesn't perform well or is not available at all due to driver issues or just not present (like servers). If you consider libraries that offer CPU rendering there are basically: - AGG (CPU only) - Blend2D (CPU only, GPU planned, but not now) - Cairo (CPU only) - Qt's QPainter (CPU only, GPU without anti-aliasing / deprecated) - Skia (CPU + GPU) - Tiny Skia (CPU only, not focused on performance) - GPU only libs (there is many in C++ and Rust) Nobody develops AGG and Cairo anymore and Qt's QPainter hasn't really improved in the past decade (Qt Company's focus is QtQuick, which doesn't use QPainter, so they don't really care about improving the performance of QPainter). So, only 2 libraries from this list have active development - Blend2D and Skia. As an author of Blend2D I hope that it will be a go-to replacement for both AGG and Cairo users. Architecturally, Blend2D should be fine after a 1.0 release as the plan is to offer a stable ABI with 1.0 - And since Blend2D only exports C-API it should be a great choice for users who want to use every cycle and who want their code to work instead of making changes every time the dependency is updated (hello Skia). At the moment Blend2D focuses on AGG users though, because AGG is much more widespread in commercial applications due to its licensing model and extensibility. However, AGG is really slow especially when rendering to large images (like 4K) so switching from AGG to Blend2D can offer a great performance benefits while avoiding other architectural changes of the application itself. BTW Blend2D is still under active development. It started as an experiment and historically it only offered great performance on X86 platforms, but that is changing with a new JIT backend, which provides both X86 and AArch64 support and is almost ready for merge. This is good news as it will enable great performance on Apple hardware and also other AArch64 devices, basically covering 99% of the market.
pizza234 3y ago
Some details in the article: > There was an attempt at making Cairo support GPU rendering, which did not work particularly well due to the library being designed around stateful operation based upon the PostScript model—resulting in a convenient and familiar API, great output quality, but hard to retarget and with some particularly slow corner cases. Meanwhile, other web engines have moved more work to the GPU, including 2D rendering, where many operations are considerably faster.

fxtentacle 3y ago

According to their benchmark, multi-threaded rendering on a Ryzen 7950X will take about 1.7ms with 4 cores for drawing 1000x polygons with 40 vertices each on a 32x32 px area, which seems like a reasonable approximation for a text character on a high-DPI display. The default font size in JetBrains fits about 2500 characters onto my screen, so I'd expect a 4.25ms frame time, meaning I am capped at 235 FPS with 4 CPU cores running at full speed. I believe the best way is probably to use Blend2D for rendering glyph bitmaps and then compositing them into the full text on GPU. Sadly, CPU memory is still plenty slow compared to GPU memory and when you need to copy around 100 MB images (4K RGB float), then that quickly becomes the limiting factor.

Asm2D 3y ago
Text rendering is something that will get improved in the future. At the moment when you render text Blend2D queries each character from the font and then rasterizes all the edges and runs a pipeline to composite them. All these steps are super optimized (there is even a SIMD accelerated TrueType decoder, which I have successfully ported to AArch64 recently), so when you compare this approach against other libraries you still get like 4-5x performance difference in favor of Blend2D, but if you compare this method against cached glyphs Blend2D loses as it has to do much more work per glyph. So the plan is to use the existing pipeline for glyphs that are larger (let's say 30px+ vertically) and to use caching for glyphs that are smaller, but how it's gonna be cached is currently in research as I don't consider simple glyph caching in a mask a great solution (it cannot be sub-pixel positioned and it cannot be rotated - and if you want that subpixel positioned the cache would have to store each glyph several times). There is a demo application in blend2d-apps repository that can be used to compare Blend2D text rendering vs Qt, and the caching Qt does is clearly visible in this demo - when the text is smaller Qt renders it differently and characters can "jump" from one pixel to another when the font size is slightly scaled up and down, so Qt glyph caching has its limits and it's not nice when you render animated text, for example. This is a property that I consider very important so that's why I want to design something better than glyph masks that would be simple to calculate on CPU. One additional interesting property of Qt glyph caching is that once you want to render text having a size that was not cached previously, something in Qt takes 5ms to setup, which is insane... BTW one nice property of Blend2D text rendering is that when you use the multithreaded rendering context the whole text pipeline would run multithreaded as well (all the outline decoding, GSUB/GPOS processing, rasterization, etc...).

Asm2D 3y ago

Thanks! I'm doing what I can to make Blend2D even faster. It's been really exciting project to work on and I have big plans with this library.

pas 3y ago

Have you heard about Vello (written in Rust) https://www.youtube.com/watch?v=mmW_RbTyj8c&feature=youtu.be https://www.youtube.com/watch?v=mmW_RbTyj8c&feature=youtu.be ?