wpf caching mechanism

[dongzhaosheng73]

I have found that repeatedly loading svg graphics can seriously affect UI performance and cause my interface to get stuck.
I don't know how to solve this situation, please help me.

[paulushub]

@dongzhaosheng73 Have you considered using threads? (see the WpfTestThreadSafety sample and other samples.)
Also, the controls provide concurrency/asynchronous methods like

public bool Load(Uri uriSource, bool useAsync = false) {}

public Task<bool> LoadAsync(Uri uriSource) {}

[dongzhaosheng73]

Can asynchronous operations be done in xaml code?
I think the biggest bottleneck is the caching problem, because one of my controls uses an svg resource as a static resource, but it gets loaded multiple times in the list, so it slows down the build speed of my entire interface.

[paulushub]

Can asynchronous operations be done in xaml code?

I do not know of any such possibility.

I think the biggest bottleneck is the caching problem

There should be a way out - but it sounds like purely WPF issue.
How about a static SvgIcon (which is an image-derived object)?

I was also thinking of x:shared but this is the documentation from Microsoft

In WPF, the default x:Shared condition for resources is true. This condition means that
any given resource request always returns the same instance.

[dongzhaosheng73]

I wonder if you can add a caching mechanism to svg controls, if the same resource exists in memory.

similar to this microsoft article: https://learn.microsoft.com/en-us/windows/communitytoolkit/helpers/imagecache

[paulushub]

I wonder if you can add a caching mechanism to svg controls, if the same resource exists in memory.

What do we cache in this case? (SvgDocument, Drawing, DrawingVisual)

[dongzhaosheng73]

Would MemoryStream be any better? I think the performance bottleneck is in the IO operation, directly from the memory stream.

[paulushub]

Would MemoryStream be any better? I think the performance bottleneck is in the IO operation,
directly from the memory stream.

Will not work well for all input types., and therefore not future proof.
SharpVectors even supports TextReader and XmlReader as inputs,
except these are not exposed in the controls yet - not requested.

[dongzhaosheng73]

Will not work well for all input types., and therefore not future proof.
SharpVectors even supports TextReader and XmlReader as inputs,
except these are not exposed in the controls yet - not requested.

No matter what the input type is, I think they should be stored in memory as a stream type. It is hoped that a unified stream type cache can be made, and when verifying the input type content is consistent, the memory stream will be converted and output directly.

[paulushub]

No matter what the input type is, I think they should be stored in memory as a stream type.

There seems to be no gain in this choice. SvgDocument will always be created, why not simply cache that instead of converting to stream, which will again be converted to SvgDocument.
In the same way, if there is no change in the document, the Drawing (a time consuming process) will always be created from the SvgDocument, so why not cache this?
Finally, depending on the target (SvgIcon, SvgCanvas), a DrawingImage or DrawingVisual is created but this is not unique to all cases as in the SvgIcon and SvgCanvas cases.

In any case creating the SVG control is a simply process, you can even just copy all the source for your control of choice and add more features including the caching, and maybe post it as PR.