[QUESTION] What is the point of using USE_DELEGATES in SkiaApi.cs?

[stepangovorko]

I found the code to dynamically load the native lib 'libSkiaSharp.*'.
https://github.com/mono/SkiaSharp/blob/master/binding/Binding/SkiaApi.cs
This is required for products are shipped for multiple platforms. But at the same time, dynamic loading is used only for the full .NET Framework, and in fact only starting from version 4.6.2.

SkiaSharp/binding/SkiaSharp/SkiaSharp.csproj

Lines 11 to 13 in e8869d1

	<PropertyGroup Condition="$(TargetFramework.StartsWith('net4'))">
	<DefineConstants>$(DefineConstants);USE_DELEGATES;__DESKTOP__</DefineConstants>
	</PropertyGroup>

SkiaSharp/binding/SkiaSharp/SkiaSharp.csproj

Line 3 in e8869d1

<TargetFrameworks>netstandard1.3;netstandard2.0;net462</TargetFrameworks>

At the moment I have a project that is built for .NET Framework 4.6.1 and is shipped for Windows (both x86 and x64). As a result, in my case, the managed SkiaSharp.dll compiled for netstandard2.0 is referenced (with static loading of the native libSkiaSharp.dll, because USE_DELEGATES = false).

Could you please explain me what is the point of using USE_DELEGATES and why is it only applied to the full .NET Framework?
How is 'libSkiaSharp.*' supposed to load for solutions shipped for multiple platforms on non-Windows OS?

[mattleibow]

USE_DELEGATES is used to switch between using the p/invokes and using lazy loaded delegates:
https://github.com/mono/SkiaSharp/blob/master/binding/Binding/SkiaApi.generated.cs#L95-L106

The reason for this is mostly for working with the logic to load the native library. In the case of Android/iOS, there is only ever one libSkiaSharp to load, so we can just use the default lookup for native libraries. On Windows, there may be several libSkiaSharp libraries in memory, so we have to manually look up each function pointer.

One use case was for VS. Multiple extensions can be installed, each with a different version of SkiaSharp. To avoid crashes, we have to explicitly load the functions for the specific binaries in the extension package. If we used normal p/invokes, then it would pick the one that was already loaded, and might crash.

SkiaSharp also only is really supporting net462 as we needed some features that came there. If you need to support NETFX, you will have to update to 4.6.2.

[stepangovorko]

@mattleibow Thanks for your answer. But I still have some questions:

1. You told SkiaSharp is needed some features that came in net462. I tried to check these specific features building Windows managed part targeting net461. But on compile time I see no issues (but I can miss something and my experiment can be not fully correct). Could you specify at least several such features or short guide how can I check it on my side?
2. In our application we builds on net461. We use Avalonia which uses ShiaSharp. Because minimum .NET Framework version supported is 4.6.2 we have to reference netstandard2.0 version. And it looks like here are no issues (both at compile time and at runtime). But at the same time ShiaSharp is using p/invokes for native API. Does it look like an issue on your side? Why lazy loaded delegates are not used in case of netstadard2.0?
3. In case of working on Linux there can be also a situation when the user application can be shipped both for x86 and x64. Why don`t you use lazy loading delegates for all platforms (As I see LibraryLoader is designed for all platforms)? Is there some benefits of using p/invokes in your case?

[mattleibow]

1. Technically, net461 can work, but to be consistent with everything, I set everyone to net462. This is also the latest version of net46.
2. Is there no way you can bump your app to use net462? P/invokes are actually better as there is less intermediate code, the reason for the delegates is, as I mentioned before, so that VS can load two versions of SkiaSharp. Unless you are supporting a plug-in architecture where two versions of skia are required to be in memory, either way will work fine.
3. Linux is also net462, so it also uses the delegates. Unless you are building a .NET Core app, then .NET core manages the native bits for you and you don't have to worry about which arch it is loading as the runtime does it for you.

[ww898]

Hi @mattleibow,

I want to connect to the discussion because I see some technical troubles with using SkiaSharp under platform with different architectures. The library is using PInvoke as simple and fast method to call native libraries. However, there is set of problem with it:

• the principle "write once, run anywhere" (WORA) doesn't work for SkiaSharp because for example I need four different .so for Linux x64 / arm64 / musl-x64 / musl-arm64 but SkiaSharp uses only one place for .so. Same bad situation with Windows x64 / x86 / arm64 / arm - only one place for all .dll.
• PInvoke isn't a gold bullet. The main issue you can't control the library:
  • it is impossible to unload the native library
  • it will use already loaded library, but which of them if you have two in memory with different versions :-)
  • You can't simply specify different subfolders for you native library if you have different version for different architectures. You should implement copy of the PInvoke interface for every combination of OS and architecture. It's a pain...
  • It is strongly required using @rpath/... for macOS because it some cases macOS processes will not find SkiaSharp library for loading.

On my opinion, using PInvoke works correctly only for system wide libraries such as dlopen / libc / libobjc / kernel32 / ... . I would recommend to use delegates in other cases.

[mattleibow]

That is what I am saying with the reason for the delegates AND the pinvokes.

On Android/iOS/UWP, we use pinvokes because we can ever only have a single libSkiaSharp. Each architecture is placed in special location, and then the OS knows which one to load. If there are duplicates, then there will be a compile time exception about duplicate symbols.

In the middle we have .NET Core which also uses the RIDs to determine which native library to load. That is why if you create a netcoreapp project now, it works across all architectures. The .NET Core runtime picks the correct architecture. If you want to support things like musl, all you have to do is just add it into the correct folder in a nuget package and let the runtime do the work: https://github.com/mono/SkiaSharp/blob/master/nuget/SkiaSharp.NativeAssets.Linux.nuspec#L50

For things like net4xx, we use delegates because there is no packaging system and we could potentially load an arbitrary number of libSkiaSharp - as is the case with several VS extensions. We have our own folder structure that the internal library loader looks at. This way, you can have all the libSkiaSharp in folders and the managed library will load: https://github.com/mono/SkiaSharp/blob/master/binding/Binding.Shared/LibraryLoader.cs#L36

With the pinvoke APIs, we can use the same API for all the architectures and OS because we make sure to use the same types in both the managed and native worlds. This means that all the things, such as the size of pointers, also change.