Some inspiration from practice - low-latency matters

[dumblob]

Some inspiration from practice - low-latency matters

[kobalicek]

I think it's difficult to even compare Blend2D with a single purpose project that has no source code available. I mean Blend2D can render arbitrary paths, transformed text, it has a composition pipeline, you can have 10k font faces loaded and render them simultaneously, etc... (and I'm not suggesting everybody would need to have 10k font faces loaded, but it's just possible with Blend2D as it doesn't need to do anything fancy to render text, it would just quickly extract the data from the TTF/OTF font and rasterize it).

Just an interesting figure - on my Zen4 machine I can render the Qt-SVG tiger demo at 115fps @ 4K resolution by only using a single thread for rendering (for comparison, Qt can render it at 35fps). And the architecture of these demos is to use QImage which is then blitted by using QPainter, so Blend2D renders to a QImage, then its content is blitted to QPainter's backing store, and then it's finally handled by Qt, most likely by using XShm or something to upload it to GPU backed memory (I'm using a dedicated GPU and X11).

I think on modern machines rendering on CPU is not really a problem - what is interesting is what the 2D library allows you to do, which is something that I would like to focus on - adding more features > making the existing faster.

In other words - performance was never something that Blend2D users complained about - users want features like layers, path-based clipping, path manipulation, and filters/effects. Yeah maybe the only thing where performance should be improved is text rendering by using a glyph cache, and I have already experimented with glyph compression that would be ideal for this task, so this feature is coming as well.

To put more context into this:

I think that if you only have 1 or 2 fonts that you need to render with a very specific text sizes, then you can do a lot of optimizations / precalculations - like creating the mentioned atlas, etc... But if you have a universal library like Blend2D - you cannot count on that. So Blend2D cannot spend 50ms by creating a 2MB font atlas per font, which would only be used once for few glyphs, for example, before the font-face is destroyed. Creating a universal library that can be used for many use cases is much more difficult than creating a library for a very narrow use case.

[dumblob]

Oh, yeah I fully agree.

I read the article with focus on a bit different aspects it seems. Namely what I saw there was the train of thought how to go about the current .

1.The (AFAIK still unsolved) issue of high quality text rendering in 3D can be approached by "leaving it up to the existing proven 2D libraries".
- conclusion for Blend2D: having good text in 3D necessitates the existing 2D font rendering infrastructure
2. For vector graphics, use SDFs in shaders where possible (SDFs which can not be computed that way will stay CPU-computed).
- conclusion for Blend2D: having an API allowing "seamless hybrid CPU/GPU computation" is a great advantage

[kobalicek]

Closing as GPU backend is a future plan.

[dumblob]

Sounds encouraging! Thanks.

[dumblob]

Btw. do you already have any ideas or plans about the hybrid CPU/GPU approach? I could not find it in the roadmap https://blend2d.com/roadmap.html .

Thanks!

[kobalicek]

Not really at the moment. That would need a lot of experimentation and time, which I don't have, so I want to focus on improving the existing backend.