Will `System.Drawing.Graphics` and `System.Drawing.Image` be part of .net Standard?

[John0King]

I saw a lot of discussion that says It's a platform specific thing. But how can a JPEG or PNG file became a platform specific thing? If the file isn't then how can the creator/reader of those file became the platform pecific thing ?

[benaadams]

System.Drawing.Graphics relies on the GDI+ features from Windows, also aren't very good in multi-threaded scenarios.

You may want to check out https://blogs.msdn.microsoft.com/dotnet/2017/01/19/net-core-image-processing/ for alternatives background and info

[bleroy]

It's correct that there's noting about the API that would restrict it to Windows. It just happens that the implementation is based off GDI+. Case in point, there's an implementation in Mono, that has even been ported to .NET Core. In summary, there's nothing in principle that would prevent System.Drawing.Graphics from being part of .NET Standard, but doing so would take time (putting it in the standard is only practical if the implementations actually exist). In the meantime, there are good 2D libraries that are available.

[danmoseley]

We have generally tried to avoid putting things in Standard for which .NET Core does not have a cross platform implementation, which is the case for most of System.Drawing (some bits that are trivially cross plat, we did put in standard).

@weshaggard can comment on how rigid this rule is.

[qmfrederik]

If the question merely is "can System.Drawing run on Xamarin and .NET Core", then the answer is a resounding yes. Correct, System.Drawing builds on GDI+ but Mono's libgdiplus is a port of GDI+ to Linux and macOS. Likewise, Mono provides an implementation of System.Drawing which now can compile on netstandard2.0 (a couple of PRs which enable that landed recently).

Long story short, the platform-specific argument is incorrect.

On the other hand, the answer to "should it be done" is not that clear. There's a lot to say about the API surface and performance which I think is one of the reasons System.Drawing did not make it to .NET Core.

If you want System.Drawing on .NET core havr a loon at CoreCompat.System.Drawing. There are other libraries which support drawing on .NET Core which can be used as well.

[John0King]

ImageSharp is I'm current looking for,but I still think that will be great if there's a crossplatform GUI component . That will make some thing like QRCode read,generate ,or Chart Framework much easier for crossplatform .

[danmoseley]

@terrajobst can you remind me what the library you was that you steered folks to who wanted drawing like functionality cross platform?

[danmoseley]

Mono provides an implementation of System.Drawing which now can compile on netstandard2.0

This is interesting and I did not know it. Has anyone tried to run it on .NET Core 2.0? /cc @terrajobst @weshaggard @AlexGhiondea FYI.

[danmoseley]

/cc @marek-safar

[qmfrederik]

@danmosemsft Yes, it works on netstandard2.0: See the GitHub project and the AppVeyor build.

There are NuGet packages targetting netstandard1.3; I'm planning to create NuGet packages for netstandard2.0 as soon as there's some kind of preview/beta for it.

Works on Linux, Windows and macOS. No guarantees about performance though :)

[qmfrederik]

@danmosemsft While we're at it, it would be much easier to package this for netstandard2.0 if #240 could get fixed

[terrajobst]

@danmosemsft

There are a few. Like, SkiaSharp and ImageSharp. Neither of them are drop-in replacements though.

@marek-safar, what's the state of Mono's System.Drawing? It seems you have an iOS version.

[qmfrederik]

@terrajobst With mono master, here's what Mono's System.Drawing's unit tests look like on .NET Core 2.0 on Ubuntu:

Test Run Summary
  Overall result: Failed
  Test Count: 1821, Passed: 1721, Failed: 92, Warnings: 0, Inconclusive: 0, Skipped: 8
    Failed Tests - Failures: 67, Errors: 25, Invalid: 0

Would you be able to open source the unit tests for the NetFX implementation of System.Drawing? It would be interesting to run those tests against Mono's System.Drawing to see just how compatible it is.

[terrajobst]

We see System.Drawing as part of Windows Forms. And WinForms (alongside with WPF) is considered proprietary Windows technology that we don't plan on open sourcing. That being said, we can certainly investigate whether we could open source part of it.

[qmfrederik]

@terrajobst Sure, sounds good. If you could investigate the possibility of sharing the unit tests for System.Drawing, I'm sure it would help those looking for a drop-in replacement of System.Drawing on .NET Core. (And looking at the 25k+ downloads of CoreCompat.System.Drawing, it's not just me :))

[marek-safar]

@terrajobst yes, there is a port of System.Drawing to run on top of CoreGraphics instead of libgdiplus but it's not complete.

Also I think @qmfrederik is asking for/requesting more NetStandard graphics API not open sourcing .NET version of System.Drawing

[qmfrederik]

Quick update - with the PRs that went into mono/master yesterday, here's what System.Drawing looks like on .NET Core 2.0:

Test Count: 1741, Passed: 1717, Failed: 16, Warnings: 0, Inconclusive: 0, Skipped: 8

Most of the tests failing actually seem to be related to netfx code failing Mono's unit tests - I'll try to dig into that.

Here is the full build output: https://travis-ci.org/CoreCompat/System.Drawing/builds/211558690

[Petermarcu]

So I went looking and it looks like there isn't a great test bed for System.Drawing that can be shared from Full .NET. Most of the test bed is really old and the primary testing of System.Drawing is through UI tests on higher level components like WinForms.

I think its great to have a System.Drawing that works everywhere and is a .NET Standard library. I don't think we need to put it in the standard (at least not yet). People that need it, can easily reference it to pull it in.

Question. If we were to open source the .NET Framework System.Drawing code, would that be interesting? Do we want to find a better way to expose Mono's version to a broader set of people? Do we want to get it into dotnet/corefx? I'd love to hear what people thing the next steps should be to leverage the various assets we collectively have and put them together so everyone can have System.Drawing :)

[qmfrederik]

@Petermarcu Thanks for looking into this!

The source code for System.Drawing is already public as part of the .NET Reference Source.

The ideal scenario (at least for me) would be that there is a System.Drawing NuGet package that comes from dotnet/corefx, or, alternatively, from Mono.

I would assume that if you open source that code (i.e. add it to the MIT-licensed reference source), Mono could adopt it and include it in Mono's version of System.Drawing, in a way similar to what has happened for other namespaces; or it would be a base for System.Drawing in dotnet/corefx.

I would be happy to contribute to the effort.

[bleroy]

@qmfrederik Just to be super clear, the source code is public, but is not under an open source license (it's MS-RSL, Microsoft Reference Source License). @Petermarcu is talking about actually putting it under an OSS license, which would enable re-use of portions of that code.

[Petermarcu]

Yeah, I'm making progress on being able to flip the license to MIT and get it checked into the dotnet/corefx repo. @marek-safar, what are your thoughts? Should we take the Microsoft code that is windows only as a baseline in corefx and then add the cross platform implementations from Mono to round it out there? I'd probably also want to try to use the Mono tests as much as possible as well. We'd be happy to produce a nuget package from corefx that will make this available if we did all that. Sounds like @qmfrederik would be interested in helping make that happen?

[qmfrederik]

@bleroy Yup, copy that - so take the rest of my messages with a disclamer "If Microsoft's System.Drawing becomes available under a MIT license, then..."

@Petermarcu Sure, happy to help. Either way would work for me - either you start from Mono's System.Drawing and integrate the Microsoft source, or you start from the Microsoft source and integrate Mono's changes to make it cross-platform.

Mono's System.Drawing currently compiles for netcoreapp2.0 and all Mono's unit tests pass on both Windows & Linux, so it may have an edge there.

/cc @akoeplinger as he helped out on some of the PR's I submitted for Mono's System.Drawing.

[akoeplinger]

The more OSS the better :)

Most of the managed part of System.Drawing is essentially wrappers around gdiplus.dll and in fact on Windows Mono's System.Drawing just calls into that. On other platforms we have https://github.com/mono/libgdiplus.

I haven't looked too closely at the code under MS-RSL because we couldn't use it in the past but replacing Mono's current managed part with it sounds fine to me.

[JulianWigman]

Maybe I'm coming from this from the wrong angle but there is presumably a lot of developed code out there that use system.drawing and a lot of developers with skills in writing it. Granted it may be GDI+ at the moment as the backend but cannot that not be gradually replaced over time with backend code that is more cross platform? You know I'd just be happy if my drawline or drawarc etc method calls would continue to work without having to reinvent lots of code on yet another 2D drawing library.!! Maybe I'm just a dreamer though! 😉

[qmfrederik]

@JulianWigman It sounds like CoreCompat.System.Darwing will help you. It uses Mono's implementation of System.Drawing, including a cross-platform implementation of GDI+ (libgdiplus) - so it should contain everything you're looking for.

[JulianWigman]

@qmfrederik Yes this is what I have been considering already. The point I was trying to make though is that both of these still sit on top of some form of GDI+ engine and then isnt it within the bounds of the coding magicians that write this underlying code to somehow move away from GDI+ but keep the frontend method structures the same. This way get away from the limitations of GDI+ you have all listed in this thread but still save millions of lines of application code from having to be rewritten. Personally I find system.drawing easy to get my mind around and looked at switching to things like directx in the past only to quickly come out in a cold sweat to step away from the keyboard to console myself over a beer that like is too short for this learning curve!!! 😄

[tidyui]

Has there been any progress on this regarding which route to take. I'm currently redesigning my trustworthy CMS-library from 2011 to Net Standard, and one of the key components I've been waiting for is at least the possibility to scale & crop images.

AspNetCore is fast as hell, my performance is over ten times faster, but on the other hand I don't think I've developed a web based (API or MVC) application for the past 7 years that hasn't relied on scaling/cropping of images, it's inevitable with all of the different devices available for consuming the content. With this said, I think that at least basic 2D image manipulation is a necessity for any good web platform these days.

Regards

Håkan

[qmfrederik]

See https://github.com/dotnet/corefx/issues/20325 for the latest

[alvesman]

I used .Net Core compatible System.Drawing implementation modified from mono project. https://github.com/zkweb-framework/zkweb.system.drawing

[aaronfranke]

What about implementing just System.Drawing.Color?

[qmfrederik]

@aaronfranke As far as I know, System.Drawing.Color is now part of netstandard 2.0 and 2.1 - see https://apisof.net/catalog/System.Drawing.Color

Most of the System.Drawing namespace has been implemented in the System.Drawing.Common NuGet package. It works natively on most versions of Windows (all except Nano Server IIRC). It works on macOS and most Linux distributions if you install libgdiplus.