Discussion: Should we change the drawing backend from NGraphics -> SkiaSharp

[chrfalch]

I'd like a structured discussion on wether we should move to SkiaSharp which is officially supported by Xamarin as the cross platform drawing backend for NControl.

[dapug]

I've spent the last few days prototyping with SkiaSharp, coming from a user whose app currently uses NControl/NGraphics.

NGraphics is definitely stalled in development. But I think this makes sense because SkiaSharp does everything and more, like, a lot more. NGraphics is dead IMO.

My app is a Xamarin Forms app. NControl allowed me to create bindable views with NGraphics under the hood. Well, it turns out, Xamarin provides SkiaSharp.Views.Forms which adds (as you can imagine) some abstraction over SkiaSharp for the purpose of Views in Xamarin Forms. Much like NControl.

I would need to do more tinkering, but on the surface I'm not sure where NControl would best fit in the SkiaSharp world. What does SkiaSharp.Views.Forms lack that NControl could pick up? Or, would that end up being added to SkiaSharp.Views.Forms anyway?

One thing that makes sense right off the top is, if you have an existing app using NControl, it might be nice not to have to port it from NControl to SkiaSharp.Views.Forms just to use SkiaSharp. But I'm not sure how many people are in that boat.

Hope this info helps.

[InquisitorJax]

Would be great to get the NControl controls on top of a more actively supported Skiasharp lib.
Perhaps something like this last round of waiting a fair amount of time for UWP support would have been less painful.

[sushihangover]

I like the fact that NControl/NGraphic combo has a lightweight footprint and does what is does well. The fact that it is pure CIL and the Xamarin linker can strip it down it is great. If there are missing features in NGraphic that are needed, I would say just fork it.

Personally if you move to SkiaSharp as the underlaying graphics engine what would NControl offer over SkiaSharp.Views.XXX? Are you going to duplicate the NGraphic API and map it to Skia? Going to expose Skia within NControl?, etc...

Taking the entire 5MB+ per platform Skia engine and the performance can be overkill for a lot of projects (a pro and con w/ SkiaSharp as its Views are heavy (memory and CPU) and not something you want to place into RecyclerViews, ListViews, etc...). But if a project needs the capabilities of Skia than I am going to use SkiaSharp.Views as I can access everything the engine has to offer.

[dapug]

One thing I am hitting as I port my project to SkiaSharp is that NControlView has touch support, and SKCanvasView does not. :( So here is an area where NControl could be really handy as a wrapper over SkiaSharp.

[vinicioslc]

Will be nice port NControl to skiasharp :3

[chrfalch]

Thanks for the feedback Vinicios - any specific details on why go for SkiaSharp and not NGraphics?

…

On Fri, Apr 14, 2017 at 7:05 PM, Vinicios Clarindo ***@***.*** > wrote: Will be nice port NControl to skiasharp :3 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#75 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA1a9GDNWB5LjP5B00ZtBOwuO9MEyASbks5rv6d0gaJpZM4MTeCO> .

[renzska]

Due to the stalled nature of NGraphics and the support for Skia from Google, I'd have to throw my vote in for moving to SkiaSharp. My reasons have to do with forward usage across more platforms as they're released (again, the stalled nature of NGraphics). However, I can't remember if NControls worked with the Xamarin.Forms Previewer, but SkiaSharp currently doesn't show the painted objects in the Xamarin.Forms Previewer (it is being worked on), so that's a downfall of SkiaSharp at the moment: mono/SkiaSharp#234

The KimonoDesigner (https://github.com/xamarin/KimonoDesigner) that's being worked on is also a benefit of SkiaSharp, but not directly related to the use of it in NControls.

[mattleibow]

@dapug I have been working on touch support for the skia views, and I think you may like what there is available. Here is the PR that I want to merge: mono/SkiaSharp#309

Here is the type that will be exposed on all views: https://github.com/mono/SkiaSharp/pull/309/files#diff-32c05fd3f2700c9c0d3bcd2f0d177c2d

public class SKTouchActionEventArgs : EventArgs
{
	public long Id;
	public SKTouchActionType ActionType;
	public SKTouchDeviceType DeviceType;
	public SKMouseButton MouseButton;
	public SKPoint Location;
	public bool InContact;
}

public enum SKTouchActionType
{
	Entered,
	Pressed,
	Moved,
	Released,
	Cancelled,
	Exited,
}

public enum SKTouchDeviceType
{
	Touch,
	Mouse,
	Pen
}

public enum SKMouseButton
{
	Unknown,
	Left,
	Middle,
	Right
}

[dapug]

@mattleibow , this looks quite promising. I went through all the code on github. On the surface, the distinction between pen/mouse/touch is one of those things that seems like an obvious little detail, but is impressive. Being applied to all views is key too. I don't have an enviro set up to build skiaharp but as soon as you push another update to NuGet I will pull it into my project where I currently have dependencies on both NControl and SkiaSharp and give this a go.