SKPaint and performance considerations

[andrey-shavelev]

SKPaint and performance considerations

[toptensoftware]

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.

[parentelement]

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.

[andrey-shavelev]

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.

[toptensoftware]

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)