Basic premise of the library is based upon a fallacy and harms existing projects.

[JimBobSquarePants]

Update: see this comment for resolution.

---

Within the dotnet ecosystem there are multiple graphics libraries available depending on your target platforms; however, if you are doing cross-platform development there is not a unified graphics abstraction. Some legacy API's (System.Drawing, I'm looking at you) only have limited support/usefulness on non-Windows platforms. SkiaSharp runs almost everywhere these days, but for many use cases the native graphics abstractions are needed.

This is fundamentally untrue. There exists cross platform graphics libraries in the .NET ecosystem that provide a unified API and experience.

ImageSharp
ImageSharp.Drawing

By ignoring existing projects Microsoft is actively harming the .NET open source community. Time would be better spent actually contributing to them to fill any feature gaps rather than reinventing something with the Microsoft label.

[charlesroddie]

@JimBobSquarePants a brief look at those repos (the name, front page and issues) suggests ImageSharp is concerned with images and image files. This is a long way from 2D graphics, where you need to draw on screen with high performance. The documentation says "We are yet to prioritize performance in our drawing APIs." and does not list any low-level 2D graphics framework support.

There is certainly some overlap because you can use ImageSharp to draw on screen, but unless you can do this very fast with minimal overhead then Microsoft.Maui.Grahpics is needed.

Time would be better spent actually contributing to them to fill any feature gaps

Suppose we need to have a well functioning 2D graphics library in 1 month. Short, but this library needs to get into dotnet6 previews and even 1 month might delay projects like GraphicsControls. Can ImageSharp get into this state in this timeframe? I.e. support CoreGraphics, Android.Graphics, Win2D, SkiaSharp for performant/memory-efficient 2D rendering? And what would be the advantages to starting with ImageSharp rather than starting with the code in this library?

More plausable than "make ImageSharp do everything" is that that users of Microsoft.Maui.Graphics can use ImageSharp to load/save/process image files in many formats, so that this library doesn't need to extend its support beyond the current jpeg + png.

[dustinmoris]

we need to have a well functioning 2D graphics library in 1 month. Short, but this library needs to get into dotnet6 previews and even 1 month might delay projects like GraphicsControls

This is really where the problem lies. Microsoft thinks they must provide a solution to every problem which a developer might ever face regardless of what it does to the bigger open source community. They make every problem their own responsibility and then bulldoze over everything else which wasn't developed in-house.

You don't get that anywhere else. Google doesn't think that they must provide a solution to every problem space someone might have. For example Go comes with a basic logging package in the standard library, but when customers wanted something better and faster then the community came up with a variety of different solutions which solve problems in different ways. Uber developed Zap and lots of other projects came about which compete. Same for web frameworks and many other domains such as graphics. Today there is a rich eco system and variety of amazing libraries which developers can use. They all co-exist and Google doesn't spend any marketing dollar on promoting a single solution and effectively suffocating everything else.

The same is true for other languages/tech stacks and they all thrive wonderfully.

Only Microsoft has this assault like attitude towards OSS which means that Microsoft teams are constantly working on their own one-stop solutions in direct competition with everyone else. They don't just do it to OSS but to their own customers as well. Microsoft is in active war with companies like Telerik, Infragistics, Redgate, JetBrains and anyone else who tries to develop something useful for .NET developers.

The problem with that attitude is not only that Microsoft creates a hostile environment towards OSS and third party developers but also that Microsoft is starting too many fights which they struggle to win. They over commit and then don't have the time, energy, resources or the insight to develop the solution which their customers actually want.

What tends to happen follows approximately this script:

• Initially Microsoft develops a quick immature alternative solution to already existing software. Their marketing and influenza(TM) folks will promote their newly developed in-house product to the extent where everything else starts losing out. However, the initial version is far from perfect and will frustrate most developers to begin with.
• Later Microsoft will iterate the initial version for 5 years or so until they finally get it right. Only problem is that it's mostly too late for many and the resentment has only grown more.
• After that Microsoft keeps to further iterate the product and come up with new and bigger use cases which overcomplicate it again and make it dysfunctional again.

In the end there is only a small 6 months to 1 year sweet spot where Microsoft has provided something useful before they made it unusable again.

I have seen this over and over again and it is truly frustrating to see how predictable Microsoft is.

[JimBobSquarePants]

Suppose we need to have a well functioning 2D graphics library in 1 month. Short, but this library needs to get into dotnet6 previews and even 1 month might delay projects like GraphicsControls. Can ImageSharp get into this state in this timeframe? I.e. support CoreGraphics, Android.Graphics, Win2D, SkiaSharp for performant/memory-efficient 2D rendering? And what would be the advantages to starting with ImageSharp rather than starting with the code in this library?

@charlesroddie The whole point is that you do not need to use those underlying frameworks.

Regarding the timeframe... Well the libraries have been around for about 6 years now, if, instead of naval gazing and continuing to push System.Drawing Microsoft had instead contributed development time then the conversation would be moot.

Regarding performance. We're not that far off drawing performance and for general operations like resizing we do a better job. Again, with assistance any performance bottlenecks could easily be fixed in that timeframe.

[Zaid-Ajaj]

This is a long way from 2D graphics, where you need to draw on screen with high performance. The documentation says "We are yet to prioritize performance in our drawing APIs." and does not list any low-level 2D graphics framework support.

@charlesroddie

The project listed ImageSharp.Drawing shows "a cross-platform 2D polygon manipulation API and drawing operations." not just for loading images

I really hope this is not the first time you actually look into the popular ImageSharp library and ecosystem, because it would mean you have started a project without exploring the existing landscape of solutions that the .NET community had come up long before and had been battle tested by actual .NET users

Please consider adding a "Prior And Existing Art" section explaining how this library compares and differs from the existing solutions, what it means for users of those different libraries and why they would use this library instead

[Aaronontheweb]

@charlesroddie isn't a MSFT employee or an author of this library, FYI - just someone in the .NET ecosystem with a different opinion - and we should welcome those differences of opinion in the .NET OSS community about the role Microsoft plays in it and how that can crowd out or cannibalize innovation that occurs elsewhere in the .NET ecosystem.

But yes, the ImageSharp.Drawing library does indeed appear to do 2D graphics so he was mistaken on that.

Whether or not Microsoft should have created this library is a somewhat moot point - it was inevitable that this library was going to be built:

Pervasive “Not Invented Here” Culture at Microsoft

Microsoft contributes to ecosystem issues through their own product development and evangelism activities, but they’ve tried to speak to those issues through initiatives like the aforementioned .NET Foundation Maturity Ladder.

I say this as an ex-Microsoft employee, a long time Microsoft fan, and a heavy participant in the .NET OSS ecosystem: Microsoft’s product culture mandates they control everything down the stack. They’re the most risk averse company of all in the entire ecosystem, when it comes to considering third party technologies, and they will only deviate from that strategy when they realize they’re playing from behind.

I don't know enough about this corner of .NET to know if these particular complaints have any merit, but Microsoft certainly hasn't earned the benefit of the doubt.

As much as it's my schtick to shit on Microsoft for hamstringing their own OSS ecosystem by competing with it at seemingly every opportunity, I'm of the opinion that this type of energy is probably better spent building some defensive moats to stop them from being successful. Microsoft's product culture is about as inflexible as they come and despite some very good intentions from high level actors within their ecosystem who want to change it, I'm skeptical it will ever change. That's why it's useful to raise these types of issues and draw attention to the problem as it happens.

But that being said, for the sake of ImageSharp and the greater .NET ecosystem, I would focus on differentiating and building moats - as exhausting as that is.

[charlesroddie]

@Zaid-Ajaj I really hope this is not the first time you actually look into... ImageSharp..., because it would mean you have started a project...

This code was created by @jonlipsky and has based on code used in production for 10 years according to readme.md, so has been in development for longer than ImageSharp, although I don't believe this is relevant to the topic, which should be about the best way to do cross-platform 2D graphics given what we have at the moment.

Not only this library but NGraphics and SkiaSharp have addressed the need for cross-platform 2D graphics in the last few years. Maui.Graphics promises to have the reliability of SkiaSharp but (on most platforms) without the large deployment size. In debates on cross-platform drawing or UI, there is always "use SkiaSharp"/"but it's 5MB", which suggests a need for a light 2D drawing library.

The project listed ImageSharp.Drawing shows "a cross-platform 2D polygon manipulation API and drawing operations." not just for loading images

Yes, as I recognized in my post ("you can use ImageSharp to draw on screen"). I was generous actually as it's very hard at the moment, but you could do it if someone writes the wrappers for various platforms.

The API is much smaller than for example Skia but that doesn't mean it's not usable: I can't immediately tell for example whether it would cover my personal usage of 2D drawing. Is the API surface of ImageSharp good enough to be used to be a basis of an entire UI system (GraphicsControls)?

@JimBobSquarePants Regarding performance. We're not that far off drawing performance and for general operations like resizing we do a better job. Again, with assistance any performance bottlenecks could easily be fixed in that timeframe.

Resizing is very image-focused. No one is disputing here that ImageSharp is great at images, and I don't believe there is an attempt to make Maui.Graphics into an image-processing library. For drawing and text operations getting to native speed is important.

This is the main question here. More important than what code has been written already even. Is there evidence that 2D software rendering performs as well as as wrapping low-level 2D frameworks?

[JimBobSquarePants]

I was generous actually as it's very hard at the moment, but you could do it if someone writes the wrappers for various platforms.

@charlesroddie It's really hard to take you seriously when you clearly have very little understanding of what you are talking about.

[charlesroddie]

@JimBobSquarePants This rudeness is uncalled for. The need for wrapping is a minor point to this dicsussion (since it doesn't affect strategy) but obviously important to users. The ImageSharp documentation describes how to create and change images but not how to create image views on platforms like Xamarin.Forms, UWP, Avalonia etc., how to update them, how to handle invalidation etc.. Since these probably require access to buffers for performance, this is a very hard task for an average user.

[JimBobSquarePants]

@charlesroddie I'm not being rude. You're arguing points without a clear understanding of the capabilities of the libraries having only taken a "brief look at those repos". This is not constructive. Perhaps it's best to wait until you have a better understanding before commenting.

[En3Tho]

@JimBobSquarePants Do not turn this conversation into small uncalled for 1v1 fight. If you have anything to prove @charlesroddie wrong then state it. Or do you expect everyone to go and thoroughly scan your library just to "have the right" to post?

[JimBobSquarePants]

@En3Tho I'm clearly not.

What I am saying, and this is really important. Is that arguing about something when you do not possess the information required to do so constructively is not beneficial to this conversation.

[benaadams]

Is that arguing about something when you do not possess the information required to do so constructively is not beneficial to this conversation.

I didn't particularly have knowledge of either library... Regardless....

There is an example of uploading ImageSharp images to the GPU in Veldrid Veldrid.ImageSharp/ImageSharpTexture.cs#L128-L147 looks fairly simple in that they are just pixel data with a specified bitmap format (e.g. Rgba32 is 4 bytes long per pixel etc)

Whether Microsoft.Maui.Graphics or ImageSharp can produce the images at 60fps to animate a screen or even if that is a goal of this library I don't know.

[En3Tho]

@charlesroddie not like it's about you (LOL) , just tagging :D

[davidortinau]

Hi @JimBobSquarePants, we do have some urgency to move dotnet/maui forward here, but we don't want to rush this and we welcome a deeper conversation. I'll reach out to set that up.

[Im5tu]

I'm completely on the fence with this one as I can see both sides of the argument. Ultimately, as a primarily package consumer, choice is a good thing for me. Sure, there are definitely things that could be done in addressing OSS owners/authors by MSFT and the DNF, and we should keep raising these points in a fair and constructive manner.

There are two things that I often think about in the OSS/MSFT drama:

• Consumers are sometimes constrained, rightly or wrongly, to use a certain set of packages. Having an OOB solution helps with this scenario. In this context, consumers would love to use package X but they just can't. We can't win easily here because we can't change the organisations or regulators (in some cases). I know of a couple of UK organisations that restrict packages based on licensing etc.
• If we do have the luxury of choosing a package, then it often comes down to: discoverability, support & feature set. Traditionally, OSS packages have a great feature set but often lack on either discoverability or support - sometimes both (I don't know enough about ImageSharp to comment further here). The world works on marketing ultimately, so there is probably work that the content creator community can do here to highlight some more OSS packages of note to help adjust some of the imbalance.

My prevailing thought though is: have constructive conservations and be nice about it. We are all humans doing our best to share what we love with everyone else. There is no place for open toxicity against one another on here or other mediums.

[JimBobSquarePants]

@En3Tho Consider yourself blocked from any of my repositories and social media. That was an unrelated post about someone who was arguing about software licenses and you have shown a considerable lack of quality in sharing it here.

[JimBobSquarePants]

@davidortinau Thanks, I look forward to your invitation.

[dustinmoris]

This issue has taken a wrong turn. I know that temperatures can go high but I would like to point out that @charlesroddie works on MathSpire which is a (rather nice) cross platform app which probably does a lot of drawing of mathematical functions and I'd be surprised if @charlesroddie hasn't spend a lot of time exploring drawing libraries in .NET at some point at least. Let's treat everyone's input with some respect.

[xoofx]

If Microsoft wants to be serious about UI, they can't use anything else that would not rely heavily on GPU rendering for 2D and that would not be cross platform. This alone is a huge work (support for GPU backends, APIs, discrepancies, 2D rendering topic which is itself years worth of development on top of a raw 3D GPU API) - specially when you start to have xplat pixel shaders in the picture, so @JimBobSquarePants I found this unfair to blame Microsoft for not considering using ImageSharp.Drawing for such a scenario.

[riverar]

Please consider adding a "Prior And Existing Art" section explaining how this library compares and differs from the existing solutions, what it means for users of those different libraries and why they would use this library instead
#47 (comment)

I think this is a great actionable first step -- build out the proposed prior art section and work on the README to clarify the story around Microsoft.Maui.Graphics. Then we can reevaluate and have a more informed/productive conversation.

[antonfirsov]

[I'm a MS employee expressing my own opinions]
[I'm also an ImageSharp contributor]

Let's try to solve this: #49 !

[dterracino]

I am a longtime developer, but haven't looked at the libraries in question, so can't comment on them. But in general, doesn't Microsoft's path forward still help us more than them not being here? Perhaps their libraries produce solutions that others can use to make their own code better.

What I have seen time and time again is that focusing on a single solution usually ends the same way - with a huge monolithic do-everything library that was trying to be exactly not that. And that doesn't matter whose library it was.

Would it be more beneficial, given the known culture, to focus instead on trying to ensure the code is licensed appropriately to best help the community? Just food for thought.

[peter-dolkens]

But in general, doesn't Microsoft's path forward still help us more than them not being here

See @Aaronontheweb's response above, but in general - no.

Microsoft has repeatedly extinguished established community-run/open-source projects by cloning them, pushing them for a few releases, then abandoning them.

Most recently they did this by cloning existing community tools to become "win-get".

We only benefit if Microsoft can commit to a long and productive future for these libraries, rather than quick snapshots in time which destroy the existing ecosystem (as the impact of a "Microsoft" approach on adoption of competitors can not be understated) before quickly abandoning them and freezing any effective development, updates, or innovation in the space.

@JimBobSquarePants has been actively updating ImageSharp over the years, and recently has been doing extensive work into refactoring to capitalize on .Net Core improvements, Intrinsics, and general performance optimizations. Microsoft meanwhile, will rush this out with .Net #.0, maintain it for 12 months, then move the team onto the next project that "needs a unified approach", leaving this code to rot until the next time they need some graphics.

[JimBobSquarePants]

Ok....

So I had a very productive chat with team directly maintaining the library. (Thanks @davidortinau et al for that!)

For clarification of the goal of the library.

Microsoft.Maui.Graphics goal is for creating UI controls using native platform graphics, and filling in with managed drawing where there is no native graphics.

The scope here is limited and as such is not threatening to the general ecosystem as it initially appeared.

We've agreed on some changes to the readme, that better communication in the future is required, and that there are also some potential opportunities for collaboration. As such I'm going to close this issue.

Thanks all.

[mvonballmo]

Ok....

So I had a very productive chat with team directly maintaining the library. (Thanks @davidortinau et al for that!)
[...]
The scope here is limited and as such is not threatening to the general ecosystem as it initially appeared.

We've agreed on some changes to the readme, that better communication in the future is required, and that there are also some potential opportunities for collaboration. As such I'm going to close this issue.

That's wonderful. While I'm happy to learn that the issue was resolved, is there any way that we can pin this comment to the top so that future readers don't have to wade through the 80% catfight in the middle?

I was linked to this issue while researching Skia vs. ImageSharp and found the initial question and a couple of responses interesting, then waded through 80% chest-thumping, then finally got to this comment that essentially says "hey, we actually talked to each other and it turns out tempest in a teapot", which is what I was hoping to learn.

[hartez]

No way to pin comments, but I added a link to that comment from the initial issue description.