You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SkObject initialization and housekeeping is quite costly in both CPU and allocations. On hot code paths it's desirable to just deal with raw IntPtr's and Skia C API and manage those manually.
Performance benefits far outweigh the loss of object-oriented API and backwards compatibility with previous SkiaSharp versions.
Since SkObject already exposes Handle property the only change that is needed is to make SkiaApi class to be public rather than internal.
The text was updated successfully, but these errors were encountered:
I'd like this as well, especially for path iterators. This seems really expensive when it's applied to every path verb:
publicunsafeSKPathVerbNext(Span<SKPoint>points){if(points==(Span<SKPoint>)(SKPoint[])null)thrownewArgumentNullException(nameof(points));if(points.Length!=4)thrownewArgumentException("Must be an array of four elements.",nameof(points));
fixed (SKPoint*points1=&points.GetPinnableReference())returnSkiaApi.sk_path_rawiter_next(this.Handle,points1);}
SkObject initialization and housekeeping is quite costly in both CPU and allocations. On hot code paths it's desirable to just deal with raw
IntPtr
's and Skia C API and manage those manually.Performance benefits far outweigh the loss of object-oriented API and backwards compatibility with previous SkiaSharp versions.
Since
SkObject
already exposesHandle
property the only change that is needed is to makeSkiaApi
class to be public rather than internal.The text was updated successfully, but these errors were encountered: