search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
15.25k stars 4.73k forks source link

Adding direct support for graphics please. #64732

Closed Barshan-Mandal closed 1 year ago

Barshan-Mandal commented 2 years ago

Background and motivation

Gui app development

API Proposal

Maui if buggy

API Usage

Graphics development

Alternative Designs

No response

Risks

No response

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details
### Background and motivation Gui app development ### API Proposal Maui if buggy ### API Usage Graphics development ### Alternative Designs _No response_ ### Risks _No response_
Author: Barshan-Mandal
Assignees: -
Labels: `api-suggestion`, `area-Meta`, `untriaged`
Milestone: -
jeffhandley commented 2 years ago

Hello @Barshan-Mandal. Thanks for submitting this issue. Could you a few scenarios where new graphics APIs would be helpful, what platforms you're looking to target, and anything else that can provide some more direction for us to understand your needs?

ghost commented 2 years ago

This issue has been marked needs-author-action since it may be missing important information. Please refer to our contribution guidelines for tips on how to report issues effectively.

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-system-drawing See info in area-owners.md if you want to be subscribed.

Issue Details
### Background and motivation Gui app development ### API Proposal Maui if buggy ### API Usage Graphics development ### Alternative Designs _No response_ ### Risks _No response_
Author: Barshan-Mandal
Assignees: -
Labels: `area-Meta`, `area-System.Drawing`, `needs-author-action`
Milestone: -
danmoseley commented 2 years ago

@Barshan-Mandal have you tried Skia Sharp? https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/graphics/skiasharp/

sukney commented 2 years ago

Add cross-platform native graphics library, skiasharp depends too much and is inconvenient to use

hez2010 commented 2 years ago

I think it's a proposal about managed implemented graphics APIs.

huoyaoyuan commented 2 years ago

A GUI app is much more complex than CLI. Different platforms have different app models and lifetime models. Even if there were simple GUI support, it would probably not happen in this (runtime) repo.

Barshan-Mandal commented 2 years ago

A GUI app is much more complex than CLI. Different platforms have different app models and lifetime models. Even if there were simple GUI support, it would probably not happen in this (runtime) repo.

You may follow java

samsosa commented 2 years ago

Maybe ImageSharp? A fully managed, cross-platform, 2D graphics API: https://github.com/SixLabors/ImageSharp

huoyaoyuan commented 2 years ago

No. GUI is very different from graphics.

danmoseley commented 2 years ago

@antonfirsov perhaps has thoughts/guidance to share here.

samsosa commented 2 years ago

No. GUI is very different from graphics.

True, but "Adding direct support for graphics please." is the topic.

antonfirsov commented 2 years ago

I don't see why would it be better to bring yet another competing graphics library to the ecosystem instead of empowering existing ones. Embedding a solution into the dotnet runtime doesn't make a it instantly better -- see the failed attempt to bring System.Drawing to Unix.

For your case (GUI app development) the best fit seems to be Maui.Graphics which provides a light-weight graphics abstraction with platform-specific implementations. It is a library you should be able to use it without pulling in the rest of MAUI.

I wonder what are your objections against consuming a library via NuGet?

tonyqus commented 2 years ago

I'm not sure if this is right place to comment about retiring System.Drawing on Linux.

I'm the major maintainer of NPOI. And your decision created this issue for NPOI. Thank you for your special gift for a non-MSFT supported open source project. And I totally agree with @huoyaoyuan.

Maintaining System.Drawing is important. I have no idea why you decided to retire this. Even libgdi is not reliable, MSFT should create its own native gdi library on Linux. Maybe this is not easy for you because MS doesn't have an expert of Linux drawing thing internally. Another choice is to create a virtual GDI library based on Mono stack. I know what you are doing that but this is a different namespace (Maui.Graphics) and this new library is not back-compatible with System.Drawing. In other words, huge number of projects have to migrate to Maui.Graphics if they want to use .NET 6. This is really bad. Because of your decision, huge huge number of efforts needed to be applied to JUST migrate legacy winform projects based on GDI to your new "cross-platform" library.

I don't wanna comment on other regions using .NET since I don't live there. Let's talk about China. I'm not sure you really understand what's happening on .NET market in China. A lot of companies choose to give up .NET because Java and Go is popular in China Internet companies and they are leading the technical market.

After reviewing the breaking changes of rencent .NET core release, I notice that the migration cost of .NET becomes very high (it may take 1-2 manmonth) to migrate existing application (.NET fx/.NET core 2.x) to .NET core 3.1/5 while working with client. This is very bad cases. To use new features introduced in newer .NET core, we have to do this kind of migration. It's NOT back-compatible at all. And the migration has no business value(but only technical value).

The last field which .NET market in China is defending is desktop based applications. Large amount of companies are using .NET to communicate with devices including medical device companies and manufactoring companies. I'm afraid if System.Drawing is retiring, it will be a big efforts of migration for these companies. Or they will choose to keep using .NET framework since there is no migration cost but how about technical support and security issue if they are using old versions of .NET framework.

I'm afraid your decision may become another good execuse for companies in China to give up .NET and embrace what they called "open source language" like Java and Go due to the perfect ecosystem. There are many choices for cross-platform application these days. So PLEASE PLEASE PLEASE reconsider your decision.

Last but not least, you may never understand how hard to maintain a community where the .NET job market is shrinking. I need your support instead of pulling the market down.

Jack-SYJ commented 2 years ago

I'm not sure if this is right place to comment about retiring System.Drawing on Linux.

I'm the major maintainer of NPOI. And your decision created this issue for NPOI. Thank you for your special gift for a non-MSFT supported open source project. And I totally agree with @huoyaoyuan.

Maintaining System.Drawing is important. I have no idea why you decided to retire this. Even libgdi is not reliable, MSFT should create its own native gdi library on Linux. Maybe this is not easy for you because MS doesn't have an expert of Linux drawing thing internally. Another choice is to create a virtual GDI library based on Mono stack. I know what you are doing that but this is a different namespace (Maui.Graphics) and this new library is not back-compatible with System.Drawing. In other words, huge number of projects have to migrate to Maui.Graphics if they want to use .NET 6. This is really bad. Because of your decision, huge huge number of efforts needed to be applied to JUST migrate legacy winform projects based on GDI to your new "cross-platform" library.

I don't wanna comment on other regions using .NET since I don't live there. Let's talk about China. I'm not sure you really understand what's happening on .NET market in China. A lot of companies choose to give up .NET because Java and Go is popular in China Internet companies and they are leading the technical market.

After reviewing the breaking changes of rencent .NET core release, I notice that the migration cost of .NET becomes very high (it may take 1-2 manmonth) to migrate existing application (.NET fx/.NET core 2.x) to .NET core 3.1/5 while working with client. This is very bad cases. To use new features introduced in newer .NET core, we have to do this kind of migration. It's NOT back-compatible at all. And the migration has no business value(but only technical value).

The last field which .NET market in China is defending is desktop based applications. Large amount of companies are using .NET to communicate with devices including medical device companies and manufactoring companies. I'm afraid if System.Drawing is retiring, it will be a big efforts of migration for these companies. Or they will choose to keep using .NET framework since there is no migration cost but how about technical support and security issue if they are using old versions of .NET framework.

I'm afraid your decision may become another good execuse for companies in China to give up .NET and embrace what they called "open source language" like Java and Go due to the perfect ecosystem. There are many choices for cross-platform application these days. So PLEASE PLEASE PLEASE reconsider your decision.

Last but not least, you may never understand how hard to maintain a community where the .NET job market is shrinking. I need your support instead of pulling the market down.

quite agree

hez2010 commented 2 years ago

@tonyqus As S.D.C deprecation document: Cross-platform consumers can reference older versions of the package to continue using System.Drawing.Common via libgdiplus, which means you can always reference the old version of S.D.C via nuet package to use it in a higher version of .NET.

But in general we do need a new build-in graphics library to supersede System.Drawing.Common, and the shape of new APIs should be similar with S.D.C as much as possible to minimize the effort of migration.

tonyqus commented 2 years ago

@hez2010 The default behavior of .NET6 is throwing the exception as described below.

Throw PlatformNotSupportedException when trying to load libgdiplus pointing to an aka.ms link with the reasons behind it and recommending stable, well-maintained open-source library alternatives

I don't think this is a developer friendly design. If System.Drawing.Common is still usable, there should be no exception thrown by default. This exception forces developers to solve this issue or migrate to another what you called 'stable' library.

And this doesn't explain why MSFT doesn't want to contribute to libgdi/libgdiplus but directly give up System.Drawing on Linux.

huoyaoyuan commented 2 years ago

And this doesn't explain why MSFT doesn't want to contribute to libgdi/libgdiplus but directly give up System.Drawing on Linux.

They explained in the original post. libgdiplus has been unmaintained for a long time. More important, it has to simulate Windows API surface.

The API surface of System.Drawing was too coupled to Windows API.

tonyqus commented 2 years ago

This is not a real explanation. It's more like an execuse. Microsoft can help maintain it or create a new similar library which can help solve the gap. I don't have concern on MSFT promoting their new MAUI interface but they should create a back-compatible library to help reduce the cost of migration This is my major concern. In .NET framework, they did a very nice job on back-compatiblity. But it's totally another story in .NET core framework.

Again, throwing exception is not a good choice. Instead, the community can choose by themselves as long as you still allow System.Drawing.Common to be used. If this is not good, why is the community still keeping using it during the past 5 years?

@danmoseley Do you think we can stop throwing exception since .NET 6.1? If you need a proposal, I can create one. Just let me know where shall I create this proposal.

tonyqus commented 2 years ago

@huoyaoyuan @hez2010 When I was a Microsoft MVP, I used to defend for Microsoft as you do. I can totally understand your opinion. And I know your background. Both of you are in university (please correct me if I'm wrong). You may hear something from your friend or classmates. But you are not practicing in the market. It's shrinking very quickly in the past 2-3 years. One of you will try to find a job very soon (because you will graduate this year). It's very possible that students like you cannot find a .NET job as a fresh developer. It's not because you are not competitive enough in the market. But it's because .NET jobs are becoming rare in China. I'm actually monitoring the .NET market in China. I even have a few friends who work as headhunters. They told me that .NET jobs just disappeared in their hunting list. Some young headhunters even don't know what .NET is because they are never assigned a .NET headhunting task. (It's not a joke.)

If the China market is good enough and I'm fine with any decision .NET team makes because we can afford to lose some .NET market in China. But now, it's very different.

huoyaoyuan commented 2 years ago

@tonyqus I do think it's important to support simple graphics and GUI, like Qt and Java swing. I also said in another issue that MAUI isn't appropriate approach. In similar issues, I never suggest MAUI, although I'm trying it myself.

Personally I dislike partially working feature. There are a lot of mixed things in WinForm and System.Drawing. I just tried to maintain System.Drawing.Common and looked at the code base. It exposes too much native Windows concepts.

One of you will try to find a job very soon (because you will graduate this year). It's very possible that students like you cannot find a .NET job as a fresh developer.

I've already received offer from MS. I also watch the .NET market sometimes. In my view, many people have stereotype of legacy .NET. Only a portion of them discuss modern .NET.

To be clear, I do suggest a first-party cross platform desktop GUI. And I do suggest to make (a part of) WinForm and WPF cross platform. But I've also watched the codebase and the activity of the team and know the difficulty. The UI team looks very busy currently.

AraHaan commented 2 years ago

Perhaps the UI team needs more members to help thin the load on how busy they are?

tonyqus commented 2 years ago

@huoyaoyuan Firstly, congratulation on getting the offer of MIcrosoft. I'm not very surprised that MIcrosoft hires MSP/MVP. And please pay attention to your opinion and comments on MIcrosoft in the public forum like github. As I know, Microsoft is not as open as you have thought. :D

Secondly, it's a pity that .NET developers in China have fewer and fewer choices while looking for a job. And you can only get a .NET offer from Microsoft instead of Microsoft partners or some other companies who are using .NET. And you are a special case because you are MSP. I suppose you and me are monitoring the same market. It's not about if the developer is using modern or legacy .NET. When the market is booming enough, your opinion makes sense. Did you think about this: why Java 7/8 (legacy Java) guys nevers worry about finding a job in China?

Thirdly, I totally understand how difficult to create a windows-concept based System.Drawing.Common. I've been coding for almost 18 years. I never say it's easy. But this is legacy debt that .NET team has to deal with. I'm also fine that they create a virtual wrapper of System.Drawing.Common based on MAUI layer. But stop wasting .NET developers' time on migration. After using .NET core, it's always about migration. Too many architecture changes.

AraHaan commented 2 years ago

I think it's possible to implement a layer based on OS level specs and the lowest of level stuff, in the end everything on a computer is about sending stuff to a specific function pointer addresses at the hardware level.

an example of impl is here: https://github.com/AraHaan/CyanOS/blob/master/src/kernel/hardwarecommunication/pci.cpp Note: implementation is not complete as I followed an youtube based tutorial years ago and never had the time to finish it up. I could technically do an VGA driver as well keyboard and mice are a prime example on how it works at the hardware level. https://github.com/AraHaan/CyanOS/blob/master/src/kernel/drivers/keyboard.cpp https://github.com/AraHaan/CyanOS/blob/master/src/kernel/drivers/mouse.cpp

I also tried making one in C++ itself as well too back then for all OS's by using only hardware function pointers and no os specific apis: https://github.com/AraHaan/CyanOS/tree/master/src/GUIToolkit

ghost commented 1 year ago

Tagging subscribers to this area: @dotnet/area-meta See info in area-owners.md if you want to be subscribed.

Issue Details
### Background and motivation Gui app development ### API Proposal Maui if buggy ### API Usage Graphics development ### Alternative Designs _No response_ ### Risks _No response_
Author: Barshan-Mandal
Assignees: -
Labels: `area-Meta`
Milestone: Future
ericstj commented 1 year ago

Closing this as we do not have plans to develop a GUI library in .NET, some suggestions for alternatives were provided above.