[FEATURE] Add a SkiaApi and SKAbstractManagedStream native abstraction

[jeromelaban]

Is your feature request related to a problem? Please describe.
For the implementation of https://github.com/nventive/Uno.SkiaSharp, some internal changes have to be made to enable WebAssembly support. All of the changes need to be made specifically at the P/Invoke (parameter shuffling, types adjustments, custom delegates, etc...) while the rest of the code remains untouched.

This requires the creation of a wasm specific version of the SkiaSharp library, and therefore requires the creation of wasm-specific dependencies, such as SkiaSharp.Extended packages.

Describe the solution you'd like
SkiaSharp should provide a way to change the native backend. e.g. a SkiaNativeBackend.Current which provides an ISkiaNativeBackend implementation.

This will enable the support for WebAssembly, while minimally impacting the structure of SkiaSharp, until the situation of the packaging of WebAssembly support settles down (NuGet/Home#8186).

[mattleibow]

@jeromelaban I had a very, very quick think and this looks to be something that may work. Just tested it on Windows and it runs. Will it work for WASM?

https://gist.github.com/mattleibow/6f0cd3efd6152fb614aa0fd803867d25

That should be a fully working gist, at least on Windows x64, here is a snippet:

public delegate IntPtr sk_surface_new_null(int width, int height);

public static class TheInterop {
  public static sk_surface_new_null sk_surface_new_null = ThePInvokeInterop.sk_surface_new_null;
}

public unsafe class ThePInvokeInterop {
  [DllImport("libSkiaSharp", CallingConvention = CallingConvention.Cdecl)]
  public extern static IntPtr sk_surface_new_null(int width, int height);
}

public unsafe class TheWasmInterop {
  public static void Init() {
    TheInterop.sk_surface_new_null = CreateProxy;
  }
  public static IntPtr CreateProxy(int width, int height) {
    var p = new sk_surface_new_null_params();
    p.width = width;
    p.height = height;
    return sk_surface_new_null(ref p);
  }
}

[mattleibow]

One important thing to note is that we initialize all the delegates, and then WASM can just override the specific ones that need adjustments. Is this useful? Will WASM override all of the methods and this is now just extra work?

[jeromelaban]

@mattleibow most of the native functions in wasm don't change, so this could definitely work. I wondering about the performance impact of using an indirect call through a delegate, vs. a virtual invocation through an interface. I don't know what LLVM does in those cases, if there's some magic optimization that helps there :)

The case of the delegate registration for the SKAbstractManagedStream ends up being an abstraction for Marshal.GetFunctionPointerForDelegate which is not yet supported by mono-wasm (it has to go through emscripten's addFunction). The best way there would be to delegate the whole registration process to the platform specific implementation (the whole SKAbstractManagedStream type initializer).

[Gillibald]

Is it likely to happen that we will get a full-featured Skia running via WASM? In my opinion, this is a special environment that needs a special build of Skia like CanvasKit. Cripleing other platforms just for one platform wouldn't be ideal. A user of SkiaSharp would expect to be able to use all features of SkiaSharp if there was a WASM build of it.

[jeromelaban]

@Gillibald this is already working, I've built a specific version of Skia from CanvasKit. This is actually more like a Skia DLL than CanvasKit, as I've stripped out everything JavaScript related.

The discussion here is about providing a minimally intrusive way to override the P/Invoke layer, so it fits the needs of WebAssembly and mono-wasm.

The outcome of the discussion could very well be that the cost is too high, and that mono-wasm needs to evolve more for this to be viable.

[jeromelaban]

Here's what it could look like, with your suggestion: unoplatform@a904780

The only particularity is the addition of _2 and others to compensate for the lack of delegate overload support.

I have not added the SKAbstractManagedStream udpate yet.

Would that make sense ?

[mattleibow]

The delegate based approach can totally be done behind some conditional compilation magic. This way, only netstandard and/or net45 is impacted. (I have updated the gist to demo this)

Interfaces will be a bit heavy and will require that ALL the methods be implemented.

[mattleibow]

@jeromelaban we can always replace the _2 and ref SKRect with a SKRect* so we can use the same delegate everywhere. Initially I wanted to be a "no unsafe" but that is not so useful at all.

[mattleibow]

And, yes. @jeromelaban what you have looks like what I am thinking. What we can do is ask some folks on the runtime team for some input on the performance and optimizations for this approach. You know of anyone we can pull in to this discussion since you have been working closely with them?

[jeromelaban]

Excellent. Without tagging them explicitly, Zoltan or Bernhard may know more more about this, but in all cases, because those are not generic delegates, they will likely perform very well.

[mattleibow]

@jeromelaban will something like this be possible in WASM? https://gist.github.com/mattleibow/7f21dd8fdcd176f035ecdbb47af8f223

@Gillibald and I discovered that we can just create a delegate and pass the GCHandle around. This way we don't need to look up pointers and use dictionaries to find instances.

I was hoping to migrate the rest of SkiaSharp to this sort of pattern as not only do we avoid a dictionary which helps concurrency, but also we get a performance improvement. We have already moved most of the types to this, but we still have the streams to do.

Let me know if this is better or worse.

[mattleibow]

Closing this as I think all the new changes and code fixes have created a place where WASM does not need this anymore.