Currently I’m trying to use anything to build UI components in TinyCLR, but I need some methods that available in NETMF but they were missing in TinyCLR (System.Drawing.Bitmap / System.Drawing.Graphics). When these methods will be available in TinyCLR ?
PTSS
March 17, 2018, 6:30am
2
Seems System.Drawing is a always difficult library to port across.
DotNet Core 2.0 is only just now starting to get parts of it.
I think its because a lot of the library has dependencies on Windows GDI and other Hardware acceleration bit & bobs!
Its a HUGE collection of libs, but maybe if you just need afew bits that dont then depend on too much, you might be able to get them out and implement your self from Mono, or maybe DotNetCores implementation…?
opened 07:26PM - 25 May 17 UTC
closed 03:59PM - 31 Jan 20 UTC
enhancement
design-discussion
area-System.Drawing
### Update: The following is the current plan.
* [x] Port the .NET Framework … implementation to .NET Core. **WIP, See dotnet/corefx#20593 .**
* [x] Move mono's libgdiplus-based managed implementation from [mono](https://github.com/mono/mono/tree/master/mcs/class/System.Drawing) to corefx
* [x] Ensure that there is a code-sharing story between mono and corefx. This likely means removing the source code from mono and importing code from the submodule link that already exists. **In progress. Mono has begun using some portions of the Windows implementation already.**
* [x] Port mono's tests for System.Drawing, making any modifications necessary to ensure that they pass on the Windows implementation, which is our baseline for compatibility. **In progress**
* [ ] Consolidate differences between the Windows and Unix versions of the library. Document all differences in behavior and mark test cases appropriately.
--------------------------------
System.Drawing has been identified as one of the top most-used assemblies that are missing from .NET Core. Although there are 3rd-party alternatives that provide more modern versions of the same functionality ([ImageSharp](https://github.com/JimBobSquarePants/ImageSharp), [SkiaSharp](https://github.com/mono/SkiaSharp), etc.), we believe there is still value in providing a binary-compatible implementation of System.Drawing itself. This issue is intended to document and track the work items involved. There are still lots of open questions; feedback and suggestions are encouraged.
## Priorities:
* Simplify migration from .NET Framework to .NET Core. We need to be binary compatible (no recompilation needed for existing assets), and we need to match the behavior as closely as possible.
* Support System.Drawing where mono does, and facilitate code sharing between our implementations. As part of this, we will be open-sourcing the original Windows implementation from .NET Framework. This should allow us to improve mono's implementation where it diverges, and hopefully reduce the maintenance burden between us by consolidating code and effort.
* **NON-GOALS**: We do not view this library as an opportunity for innovation, nor will we invest significant amounts of effort into optimizing or refactoring it. High performance, rich OS-specific functionality, and a redesigned, modern API are not areas we are interested in investing in as part of this effort. There are alternative libraries which target all of those issues and more.
# Plan
System.Drawing is, fundamentally, a very thin wrapper over the GDI+ component on Windows. Worse yet, it is not available for UWP applications, so support is limited strictly to Win32 applications. This makes cross-platform implementations difficult, and the largest chunk of work involved with this effort will be figuring out how we can support the library on all of our platforms, and maintaining compatibility between them. There are several existing implementations that we can leverage, but none will support all of our platforms by themselves. We may need several distinct backends in order to get full cross-platform support, although some options could avoid that. The below chart maps implementation approaches (rows) with platform applicability (columns):
<empty>|Win32 | UWP | macOS | Linux / Others
-----|--------|-------|---------|---------
.NET Framework Version (GDI+) | ✓ | X | X | X
Direct2D/Win2D|✓|✓|X|X
Mono/libgdiplus|✓|X|✓|✓
Xamarin/CoreGraphics|X|X|✓|X
Managed|✓|✓|✓|✓
### .NET Framework Version (GDI+)
This is the existing implementation from the .NET Framework on Windows. It is a very thin wrapper around GDI+.
* :heavy_check_mark: Baseline implementation. Well-tested, stable.
* :x: Can only be used in non-UWP Windows apps (Win32).
### Direct2D/Win2D
In order to get UWP support, we could implement a compatibility layer over Direct2D, or Win2D.
* :heavy_check_mark: GPU acceleration
* :x: Only buys us UWP support over the existing .NET Framework implementation.
* :x: High implementation cost
* Can be shared between Win32 and UWP applications (Windows 8+ only).
### Mono/libgdiplus
This is the implementation used in mono. It uses a complicated native shim called "libgdiplus", which relies on a large set of native binaries.
* :heavy_check_mark: libgdiplus is available in a large number of package managers across the Unix ecosystem already. This means we can treat the dependency the same way we do the other native dependencies for .NET Core.
* :x: Native code adds a lot of complexity for new devs.
### Xamarin/CoreGraphics
This is a specialized implementation used by Xamarin, in support of macOS and iOS. Unlike the "libgdiplus" mono version, it only uses CoreGraphics (a system component).
* :heavy_check_mark: No extra native dependencies; only uses system libraries.
* :x: macOS-specific. Could be used for iOS (not supported by .NET Core yet).
### Managed (ImageSharp or custom)
One option is to implement the library in managed code. We can call into an existing library, like ImageSharp, for image-processing and graphics functionality. This is very desirable for a lot of reasons, but it does have a higher implementation cost.
* :heavy_check_mark: Can be used everywhere.
* :heavy_check_mark: Can achieve uniform behavior everywhere (at the expense of conformity with .NET Framework).
* :heavy_check_mark: Lower maintenance costs in the long-term.
* :x: High implementation cost.
## Windows-Specific
One option is to treat the library as a Windows-specific component, similar to Registry. Attempting to install and load the library on other platforms would throw PlatformNotSupportedException's, as Registry does.
## Tests
We do not have a very good existing test suite in the .NET Framework. The library is mainly covered indirectly, through other components like WinForms. Mono has a good set of conformance tests for their implementation, which we should be able to re-use. Where appropriate, we should also consider test cases which directly compare output from the .NET Framework implementation and other implementations (assuming we choose to support such things).
## Location
An open question is where this library should live. If we take third-party dependencies to support some platforms, we may not want this code to live in corefx.
## Printing Functionality
One thing skimmed over above is the fact that System.Drawing exposes a lot of functionality for printing images and documents. This poses a different problem from image-processing and graphics, which can be implemented portably. We may decide to exclude all printing-related portions of the library.
## Future investments
Once the library is supported on all platforms, we will accept small, targeted improvements to the library, keeping in mind that legacy compatibility is the only important metric for the library. We will not want to merge any code that refactors, optimizes, or augments the Windows version until we have a fully-working cross-platform implementation. This matches our strategy with other compatibility libraries, like System.IO.SerialPort.
@marek-safar @jimbobsquarepants @ViktorHofer @qmfrederik @karelz
Good luck!! I’m in similar boat with needing something in Core that’s just not there yet…!