Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE] Expose SkiaApi class #1205

Open
kekekeks opened this issue Apr 1, 2020 · 1 comment
Open

[FEATURE] Expose SkiaApi class #1205

kekekeks opened this issue Apr 1, 2020 · 1 comment

Comments

@kekekeks
Copy link
Contributor

kekekeks commented Apr 1, 2020

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.

@daltonks
Copy link
Contributor

I'd like this as well, especially for path iterators. This seems really expensive when it's applied to every path verb:

      public unsafe SKPathVerb Next(Span<SKPoint> points)
      {
        if (points == (Span<SKPoint>) (SKPoint[]) null)
          throw new ArgumentNullException(nameof (points));
        if (points.Length != 4)
          throw new ArgumentException("Must be an array of four elements.", nameof (points));
        fixed (SKPoint* points1 = &points.GetPinnableReference())
          return SkiaApi.sk_path_rawiter_next(this.Handle, points1);
      }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: New
Development

No branches or pull requests

2 participants