Replies: 3 comments 6 replies
-
Didn't try but looking at the code you should make sure to dispose all disposable skia objects. Otherwise they will get disposed using the finalizer which is basically THE global lock you are looking for. |
Beta Was this translation helpful? Give feedback.
-
I am trying to do something similar, and your question made me nervous about my own project, so I did some profiling. There are some gotchas in your test program:
You might need to increase your iteration count before the runtime starts the number of threads you expect. You should double check what it decides to do (e.g. with Visual Studio's Diagnostic Tools).
|
Beta Was this translation helpful? Give feedback.
-
I remember trying to use Skia from multiple threads and it was failing, so this is weird that now you're able to safely call it inside
Conclusion: You can optimize some parts of Skia but it was built to draw shapes one by one, not parallel as OpenGL on GPU, which means that you will lose most of processing time on array iterations or memory allocation. |
Beta Was this translation helpful? Give feedback.
-
I have been experimenting with performing SkiaSharp rendering across multiple threads.
The idea being that I want to render 8 different canvas' as fast as I can. So I figured that as Skia is thread safe I can just render each canvas in its own thread. So this should be one of those 'embarrassingly parallel' problems, right?
Well, it works ... but the timings are not what I would expect.
First, here is the results processing all 8 sequentially (no parallelism)
You can see I have 25 iterations to "warm" things up, and you can see that each canvas takes about 22ms to complete.
Secondly, here is the same thing, but instead run using a parallel foreach
The total is faster, but not as fast as I would expect, oddly, now each canvas takes much longer to complete? they have gone from 22ms to 60ms? which sounds to me like there is some resource contention (locking?) going on?
Any thoughts on what might cause this?
For reference you can uncomment the SpinWait and comment out the render to get an idea of what kind of parallelism you should get. On my 4 core (8 logical) machine, I expect to see a speed up of 4x - 8x (which is what I see with the spin wait)
Here is the full code
Beta Was this translation helpful? Give feedback.
All reactions