Add caching to DrawShapedText

[MichaelRumpler]

Description of Change

This enables a user to set a cache duration. When set to a value > 0, it caches the SKShaper and the SKShaper.Result thus repeated calls with the same font and/or text are faster.

Bugs Fixed

• Fixes [FEATURE] Add caching in DrawShapedText #3032

API Changes

Added:

• public static void SetShaperCacheDuration(this SKCanvas canvas, uint milliseconds)

Behavioral Changes

If the cache duration was set to a value bigger than zero, DrawShapedText will cache the SKShaper and the SKShaper.Result for that amount of milliseconds. Therefore repeated calls with the same SKFont and/or string will be faster.

If the cache duration is set to 0, then the cache will be cleared, all contained SKShaper objects disposed and caching will be disabled.

The default cache duration is 0. So if SetShaperCacheDuration is never called, DrawShapedText works as before.

Required skia PR

None.

PR Checklist

• Has tests (if omitted, state reason in description)
• Rebased on top of main at time of PR
• Merged related skia PRs
• Changes adhere to coding standard
• Updated documentation

[mattleibow]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[taublast]

Very nice one!!

Possible to avoid ConcurrentDictionary? IMHO it affects very badly animations scenarios, triggering GC due to its allocation mechanics, thus creating messy lag spikes during animations.
Once one starts a gaming loop that might come into play.

Maybe add a lock to a Dictionary.. Just thinking.

[mattleibow]

Is it possible to use System.Runtime.Caching.MemoryCache?

https://learn.microsoft.com/dotnet/api/system.runtime.caching.memorycache

Not sure if this is a good thing or not? Do people use this API? Is this sufficient?

[mattleibow]

/azp run

[azure-pipelines]

Azure Pipelines could not run because the pipeline triggers exclude this branch/path.

[MichaelRumpler]

I didn't want to introduce another dependency. But I can try it and see what the benchmarks say.

A Dictionary with lock was a bit faster than the ConcurrentDictionary, but not very much. What I actually planned, but didn't find the time to is to look at the source of System.Runtime.Caching and see if I can do something similar.

[MichaelRumpler]

I tested System.Runtime.Caching.MemoryCache but it has several drawbacks:

• it uses a string as key
• it stores an object which must be boxed

Both make it slower than the Dictionary<int, Tuple>.

Here are the benchmarks with the cache variants:

Method	Mean	Error	StdDev	Gen0	Gen1	Allocated
DrawShapedAscii	134.396 us	0.4493 us	0.4203 us	0.2441	-	3144 B
DrawAsciiWithShaper	19.046 us	0.1644 us	0.1283 us	0.3052	-	2744 B
DrawAsciiWithConcurrentCache	9.845 us	0.0486 us	0.0455 us	0.0916	0.0763	848 B
DrawAsciiWithDictionaryCache	9.575 us	0.0355 us	0.0315 us	0.0763	0.0610	752 B
DrawAsciiWithRuntimeCache	10.934 us	0.0564 us	0.0528 us	0.1831	0.1526	1560 B
DrawShapedLigatures	191.784 us	1.3686 us	1.2133 us	0.2441	-	3144 B
DrawLigaturesWithShaper	72.422 us	0.5261 us	0.4921 us	0.2441	-	2744 B
DrawLigaturesWithConcurrentCache	8.561 us	0.0280 us	0.0262 us	0.0916	0.0763	848 B
DrawLigaturesWithDictionaryCache	8.372 us	0.0513 us	0.0480 us	0.0763	0.0610	752 B
DrawLigaturesWithRuntimeCache	10.120 us	0.0264 us	0.0206 us	0.7019	0.6714	6072 B
DrawShapedEmojis	62.447 us	0.2296 us	0.2035 us	0.1221	-	1888 B
DrawEmojisWithShaper	17.385 us	0.0405 us	0.0338 us	0.1526	-	1488 B
DrawEmojisWithConcurrentCache	13.649 us	0.2212 us	0.2069 us	0.0916	0.0763	848 B
DrawEmojisWithDictionaryCache	13.553 us	0.1254 us	0.1173 us	0.0763	0.0610	752 B
DrawEmojisWithRuntimeCache	15.427 us	0.2149 us	0.2010 us	0.7019	0.6714	6120 B
DrawShapedRandom	125.474 us	1.1728 us	1.0397 us	-	-	1943 B
DrawRandomWithShaper	10.477 us	0.0267 us	0.0209 us	0.1831	-	1543 B
DrawRandomWithConcurrentCache	7.811 us	0.0747 us	0.0662 us	0.1068	0.0992	911 B
DrawRandomWithDictionaryCache	7.538 us	0.0872 us	0.0773 us	0.0916	0.0763	815 B
DrawRandomWithRuntimeCache	9.752 us	0.1542 us	0.1367 us	0.1831	0.1678	1582 B

The project with the benchmarks for the various variants is on https://github.com/MichaelRumpler/SkiaTextRendering.

As you can see the simple Dictionary with a lock was always fastest with the least amount of memory used. So I changed it to this now.

[nd1012]

the simple Dictionary with a lock was always fastest

In comparsion with the ConcurrentDictionary this is only true, as long as you don't use the specialized concurrent access methods like GetOrAdd, TryGetValue, TryUpdate and TryRemove. If you'd implement them using a simple lock statement, the ConcurrentDictionary implementation would be way faster. I can tell this, because I've implemented it just a few days ago, and benchmarks showed me a huge performance difference - so I removed my implementation with lock, finally, because 5.000us (Dictionary with lock) vs 79us (ConcurrentDictionary) during heavy multithreading doesn't really need a discussion.

Anyway, if you access the dictionary with dict[key] only, ConcurrentDictionary wouldn't have better performance than a Dictionary with lock.