I was aware of cairo, skia, nanovg, the Qt drawing libs, and the ones with OpenGl and Vulkan backends FastUiDraw and VkVg. Recently I heard of Blend2d.
Cairo is known for good quality and various backends, but has limited speed and no threading support. Drawing quality is less important as high DPI displays become more popular. The GPU supported libs FastUiDraw and VkVg may have their own problems, and I never saw performance comparisons to cairo. But Blend2d offers comparisons, and seems to be much faster than cairo in most examples. Unfortunately currently there are only GUI examples for Qt provided.
So I wonder if it may be possible to use Blend2d with GTKDrawingArea? I would assume that we would have to generate a cairo compatible source surface and blit it to the cairo context for each draw call? Should be some overhead unfortunately. Although memory bandwidth is generally more than 10 GB/s for a 8k display that blit may take a few ms in best case, which is a significant amount of course when the display has a 120 Hz refresh rate. So I am not sure if testing Blend2d in GTK would make sense at all? Maybe for very dynamic interactive data, like 2D CAD, 2D games and street map display. E.g for zooming operations where smart caching parts of the picture do not work? Or for situations where many entities move at the same time. For GTK4 we have GSK with vulkan support now of course, which may be used internally. But I am not aware of its use for custom drawing as done with the GtkDrawingArea.
License is zlib, which is called compatible with GPL. Well it is written in C++, but has a C API.
Looks kinda interesting but I don’t expect GNOME/Gtk will use it (if nothing else we have Gsk now) and being C++ is a bit of a challenge for that anyway.
Image seems to have a getData (not that the docs tell you anything about it) which can presumably be passed to cairo_image_surface_create_for_data
If your drawing is particularly low performance you should think about caching a surface instead of redrawing on ::draw
Yes indeed. It is not difficult to use blend2d with GTK. We can let blend2d allocate the bitmap, or we can create a cairo image bitmap and let blend2d write to that one. I tried both from plain C and GTK4 wayland, and did a plain animation with a bitmap created by cairo. CPU load is similar for drawing a moving sin curve with cairo directly or with blend2d. I think in both cases at least one blit operation is involved, which generates a significant part of the total load.
So I am not sure if using blend2d really pays off. Maybe when we have to draw really a lot stuff and when caching is not easily possible. Blend2d docu does not really exists currently, I had to guess how functions should be used, and for most functions I have still no idea. Cairo has the benefit of having multiple backends including SVG and PDF, which blend2d currently does not have. So I think I will continue using cairo for now.
Funny fact what I learned: The cairo default surface in the cairo draw event for a GtkDrawingArea is a recording surface, not an image surface, at least for GTK4 with wayland!