Unable to create new Image<TPixel> from VB.NET due to the unmanaged constraint

[tocsoft]

There is a user on Stack Overflow trying to create a new image using VB.NET. https://stackoverflow.com/questions/61839616/imagesharp-draw-image-on-image-in-vb-net

Image sharp has an issue at the moment where its not possible to new up a new Image<TPixel> or call any of our TPixel based APIs from VB.NET as all our TPixel APIs have the unmanaged constraint and that is not (and apparently will not be supported in VB.NET)

We need to come up with a solution to this.

Related

dotnet/vblang#300
https://stackoverflow.com/questions/61839616/imagesharp-draw-image-on-image-in-vb-net

[tocsoft]

First thought for a quick win create a static Image.Create(width, height) set of APIs that will new up the the class on behalf of the user and return it to them in the unconstrained Image base class form.

That would unblock most APIs except direct pixel access.

[Sergio0694]

Whoops, I think this is my fault 😅

See #1122.

[Bunnywood]

I see this issue has been closed, but I have just downloaded the latest version to try out and the problem still exists.
Are there any plans to support VB users, or should I be looking elsewhere.

I was using the code in the "Initialising New Images" section of the following page
https://docs.sixlabors.com/articles/imagesharp/gettingstarted.html

Thank you!

[AraHaan]

I would say convert everything to C#, I used to have a program written in VB6, then I converted it to VB.NET and then converted it to C# and I was happy for the performance benefits gained from using C# instead of VB.NET.

[antonfirsov]

@Bunnywood do you do manual pixel manipulation? If not, non-generic API variants should be fine.

[JimBobSquarePants]

I see this issue has been closed

No it hasn't. It's still open, however I cannot see us being able to fix it without VB.NET adding the language support.

[JimBobSquarePants]

@Sergio0694 Is there any way we could hide the keyword from the top level API for V3?

[Sergio0694]

@JimBobSquarePants The sensible answer is: not really, no. The unmanaged constraint is by-design viral just like async is, so you can't just "opt-in" into considering an arbitrary type argument as being unmanaged when you need it. The best you can do is to check whether a given type argument does in fact respect the constraint, but you can't go further than that.

...That being said, if we reeeeeeally wanted to, yes technically we could hide that keyword from public APIs. Assuming that we just documented those type parameters to always have to respect the unmanaged constraint, we could just do validation at runtime (or rather, at JIT time, there is no runtime cost), which is the same approach taken by the BCL as well (eg. see here). The obvious issue at this point is: how do we bridge our public APIs without the unmanaged constraint, with our internal ones (as well as our public ones in other namespaces/types that we're fine leaving with the public unmanaged constraint) that rely on that constraint?

There are two possible scenarios I can see for each API here:

• It doesn't actually need the unmanaged to work, it just needs to know the input type T is unmanaged. In this case we could just remove the constraint there, add the intrinsic check (IsReferenceOrContainsReferences<T>()) and we're good.
• It does need the unmanaged constraint. In this case we do need to somehow "opt-in" into making our current type argument(s) being considered unmanaged by the language, from a context where they're not. This is not currently expressable in C#, as far as I know. But, what if we didn't write this specific bit in C# at all? 🙈

Consider this scenario where the Image<T> class didn't have the unmanaged constraint, but needed it for an API.
We could basically split these public APIs into:

• A public API acting as a stub/proxy to the real API, without the constraint
• An internal one having the unmanaged constraint, with the same logic as we have now

We can then invoke the second from each stub by using Fody.InlineIL:

// No top level unmanaged constraint
interface IPixel<TPixel>
    where TPixel : struct, IPixel<TPixel>
{
}

// Same here as well, just the struct constraint
class Image<TPixel>
    where TPixel : struct, IPixel<TPixel>
{
    // Some public API on Image<T>, this is just a stub
    public void Foo()
    {
        if (RuntimeHelpers.IsReferenceOrContainsReferences<TPixel>())
            ThrowHelper.ThrowInvalidTypeWithPointersNotSupported(typeof(TPixel));

        IL.Emit.Ldarg_0(); // load "this"
        IL.Emit.Call(MethodRef.Method(typeof(Image<TPixel>), "FooCore").MakeGenericMethod(typeof(TPixel)));
        IL.Emit.Ret();
    }

    // This is the actual API, where we can use the unmanaged constraint. Note how it's a static
    // method taking the same "this" instance as input. Here we're guaranteeing that T will always
    // be the same as TPixel, and we'll just use T from now one, and we'll "see" the constraint.
    private static void FooCore<T>(Image<T> @this)
        where T : unmanaged, IPixel<T>
    {
        Console.WriteLine($"FooCore<{typeof(T)}>");
    }
}

So, this works. I should note, there is no reflection involved, there are no additional NuGet dependencies (they're all build-time private assets), and all of this will just get compiled down to "perfect" IL, and resulting in the same good codegen we have today. So, assuming we actually decided to do this, it would in theory be viable and it would solve this issue.
Make of this what you will though 😄

[JimBobSquarePants]

Wow @Sergio0694 thanks for such a comprehensive response! 😍 I was expecting a few lines at most.

Lots to think about. The Fody example is interesting though perhaps unwieldy given the shape of our API. I'd have to do a thorough investigation (delete the unmanaged constrain and see what methods complain 😜) to determine how viable that is.

[hamarb123]

I think I have a solution that could work, here's how it could work.

Basically we can use Unsafe.As and Unsafe.SizeOf to re-interpret the pixel type to an unmanaged type whenever required (along with checking that types are valid with IsReferenceOrContainsReferences). Depending on which APIs you use this may or may not require knowing the possible sizes in advance (this would only really be the case if the API requires a ref TPixel parameter and doesn't have something like a Span overload); ie. you may need to say pixels can only be 1, 2, 4, 8 bytes in size (or whatever the current allowable sizes are), but I think it is quite likely this can be avoided.

I'd be happy to have a much more thorough look through the code and see what exactly would be necessary if you'd like; I'd also be interested in making a PR if the project owners would be alright with it.