toptensoftware
SKPaint and performance considerations
Hello,
I have a performance issue with large amounts of text. That is to say, hundreds and thousands of labels on a large whiteboard. While investigating the performance of RichTextKit, I found out that caching of SKPaint objects and reusing them between draw iterations saves up to 50% of render time. I run it on macOS and also in blazor wasm.
At the moment, all SK* resources are created on the fly and disposed right away. https://github.com/toptensoftware/RichTextKit/blob/beb262ed21087b1600837a56336900f2c24f3b3a/Topten.RichTextKit/FontRun.cs#L604C1-L605C50
Is there a chance they could be cached?
Regards, Andrey
Are these thousands of labels all visible at once?
Usually you should clip those down and just paint the visible ones and normally a full screen of text can be rendered quite easily by RichTextKit.
If you're actually painting thousands of labels that are all visible I'd suggest caching the rendered results and doing partial updates when they change.
Agree with Brad. I tested with a couple million words and rendering every frame (due to having to use a shared Skia instance in Avalonia) and everything was buttery smooth... Apply styles, typing, scrolling, copy and paste. The only thing that was slow, as expected, was if I did a Select All and applied a style to the entire document, but even then it performed faster than MS Word for the exact same text and operation.
Thanks for your suggestions. There are indeed several user scenarios when all these labels are visible at once. For instance, when the whiteboard opens, it opens in a bird-eye view. Caching of rendering results is already something that I have. However, it doesn't cover everything. Zooming in/out often requires redrawing the whole thing when users are in a bird-eye view. There are other technics that can help tackle this, like view degradation, for instance. Still, at some point, you have to redraw the whole thing, and otherwise smooth navigation gives a lag.
I'm happy to consider a pull request for caching SK objects, so long as:
- it doesn't affect memory usage too severely and
- everything is cleaned up correctly
- doesn't require API changes if you're not using caching. (ie: doesn't break existing code)