Added Render Canvas Benchmarks

[inforithmics]

Method	Mean	Error	StdDev	Min	Max	Median	Allocated
RenderDirect	3,921.8 ns	12.92 ns	11.46 ns	3,905.0 ns	3,943.1 ns	3,922.4 ns	-
RenderDirectLessPoints	617.4 ns	1.36 ns	1.27 ns	614.6 ns	619.6 ns	618.0 ns	-
RenderRotationCanvasEveryTime	1,711.8 ns	5.09 ns	4.76 ns	1,705.4 ns	1,722.6 ns	1,711.2 ns	-
RenderScaleCanvasEveryTime	6,832.4 ns	18.03 ns	15.05 ns	6,812.3 ns	6,866.2 ns	6,832.2 ns	-
RenderTranslationCanvasEveryTime	3,014.1 ns	9.29 ns	8.69 ns	3,002.0 ns	3,031.2 ns	3,015.2 ns	-
RenderTranslationScaleCanvasEveryTime	6,829.9 ns	10.97 ns	9.72 ns	6,816.9 ns	6,849.0 ns	6,828.0 ns	-
RenderRotationCanvasOnce	1,651.5 ns	3.74 ns	3.50 ns	1,644.9 ns	1,657.8 ns	1,651.2 ns	-
RenderRotationPath	1,488.8 ns	29.53 ns	34.01 ns	1,455.7 ns	1,585.4 ns	1,476.3 ns	-
RenderOffCanvas	41,133.9 ns	426.43 ns	398.88 ns	40,604.7 ns	41,739.2 ns	41,053.2 ns	-

[inforithmics]

I tested out what influences Render Performance and I discovered following things.

1. Translation is cheap (no effect).
2. Rotation seems to use less time (not sure why).
3. Scale doubles the RenderTime (10 Times scale, 2 time render time).
4. Scale and Translation is the same as scale.
5. Transforming the Path seems slightly faster than transforming the Canvas (After transforming the Path I have to revert the transformation of the path.
6. 10 Times Less Points is 10 Times Faster.
7. 10 Times more points off Canvas is 10 Times Slower.

So Conclusion.

Transforming is relatively cheap.
Reducing the Geometric Complexity makes it much faster. Because in the Scale level of the earth the path shouldn't be on meter resolution.

So I could use Something like a GemetricSimplifier to reduce the Path before translating it to a Path, And caching the SkPath on the Geometry. Or use the The ZoomLevel for caching. The higher the Zoomlevel the more complex the path.

Here the GeometrySimplifyProvider.
https://github.com/Mapsui/Mapsui/blob/master/Mapsui.Nts/Providers/GeometrySimplifyProvider.cs

[pauldendulk]

Thanks for you systematic analysis!

Some remarks:

• There may be other options to do transformation. I know we have several different ways of transforming in our code (not so nice). I think the nicest solution is to first build a transformation matrix and then apply that in the simplest way. Is there no option to pass it in as a parameter to the skia draw function? (sorry I have not looked at the rendering code for quite a while).
• We expect drawing more points affect performance because Skia just has to draw more. I wondered if scale is in that same category. Drawing at larger scale simply means coloring more pixels. Could that be? Such a test is still useful to have an idea of how such settings influence performance but when working on a performance optimization we should compare identical images.
• Simplify also make things uglier. Especially if two simplified polygons are drawn next to each other gaps will show between them. I think this should be an option for the users, but not something we should do in our core.
• Caching often causes headaches. Sometimes you get memory leaks that can are found in production after running the app for days. We will need caching to optimize performance but we have to have very clear where and how it is used and be sure it is implemented correct.
• Faster when rotated is surprising. I can imagine that a different kind of technique is used. Pixel interpolation might work different. This may result in lower quality.

[inforithmics]

I think actual Performance Improvements should be done on a seperate pullrequest. So this adds mainly the RenderBenchmark and some extenion Methods for Performance improvements.

So I think the SkPath should be created resolution independent. And then transformed to the correct resolution.
Then the transformed Path could be kept for faster rendering

[pauldendulk]

Looks good, thanks.