SkiaSharp vs ImageSharp

[akhanalcs]

Looks like a lot of packages used in this library use bloated/ clunky Skia library.
Why not just use ImageSharp instead of Skia?
ImageSharp is performant and easy to use and usage of it in library like this should help the .NET open source community (ImageSharp in this case).

[swharden]

Hi @affableashish, I too am interested in the answer to this question.

Note that JimBobSquarePants, the creator of ImageSharp, contributed some interesting discussion in #47. However, based on the overall sentiment there, I did not get the impression that an ImageSharp abstraction is currently in development.

[akhanalcs]

Hi @swharden , I don't think ImageSharp abstraction is currently in development in Maui.Graphics. I'm just trying to start a discussion on why we should be using ImageSharp instead of SkiaSharp.
I didn't realize JimBobSquarePants had started interesting discussion on this already. Thank you for the link! 😊

[mvonballmo]

Note that JimBobSquarePants, the creator of ImageSharp, contributed some interesting discussion in #47.

tl;dr: Maui.Graphics uses SkiaSharp because it is a 2D-rendering library rather than just an image-manipulation library.

For future readers: The discussion itself is not very interesting, but the conclusion is. The title of the issue is "Basic premise of the library is based upon a fallacy and harms existing projects." (referring to Maui.Graphics), which doesn't feel super-constructive (and wasn't). There are long screeds about how harmful MS is for everything OSS. The final comment is worth reading, as it explains that it turns out that the harshness of the issue title was completely unwarranted (as admitted by the original poster). Good conclusion; typically unproductive Internet discussion.

There is no conflict. Skia's support for images is weaker than ImageSharp's but it allows using GPU rendering on supported platforms whereas ImageSharp is for in-memory data (CPU-bound).

[bmitc]

ImageSharp does not support GPU processing and is CPU only. That prevents it from drawing directly to a GPU context or device such as with OpenGL or Vulkan. See here: SixLabors/ImageSharp.Drawing#233

[audacode]

Just for anyone reading this now: A few months after this question was posted, the ImageSharp license changes. It is no longer using an acceptable license for the use suggested by the original posted. Yes, it is true ImageSharp is a nice library with an elegant API.