Xamarin.forms: [Enhancement] SkiaSharp Controls

[KSemenenko]

Summary

I think that the option to draw custom controls and visual elements with the help of SkiaSharp right in xaml in Xamarin.Forms was useful to everyone.
This is a good opportunity to do what Flutter does only in Xamarin.Forms.

API Changes

<SkiaCanvas>
    <SkiaGrid>
        <SkiaRect Width="50" Height="50"/>
        <SkiaLabel Text="SomeText"/>
        <SkiaStack>
             <SkiaLabel Text="SomeText"/>
             <SkiaLabel Text="SomeText"/>
        </SkiaStack>
    </SkiaGrid>
</SkiaCanvas>

[andreinitescu]

I love SkiaSharp, but depending on the requirements, the size of SkiaSharp can be important (not sure, I think it's around 5MB?) I think @mattleibow has up to date info on this.

[jfversluis]

I think indeed the biggest concern with this is that we have to take on a dependency on SkiaSharp which is really not something we want to do.

[KSemenenko]

We can create separate library like Xamarin.Forms.Map @andreinitescu @jfversluis

[KSemenenko]

@andreinitescu I know how much you like SkiaSharp, can we make it more accessible for Xamarin.Forms?

[jsuarezruiz]

The idea reminds me this nice Matthew project.

If we are talking about facilitate drawing something custom from XAML (shapes, gradients, etc.) it seems as a possible option (among other options). @jfversluis is right about the weight of the dependency, it should be a separate package (Xamarin.Forms.Drawing for example).

If the idea is to have the entire set of Xamarin.Forms controls with support in SkiaSharp, we have several important points here.
From the outset, would not be in any case a new "backend" (Xamarin.Forms.Platform.Skia)?. And at this point we would have to solve several questions:

• How would be the default rendering?, simulating the native control in each case?, having several rendering options like Cupertino, Material, etc?
• It would be necessary to solve important topics that in native we have them well covered as the accessibility, etc.

With this second idea, I suppose it would be interesting to have other features like Page or View tags to choose between use native control or SkiaSharp, etc.

[KSemenenko]

@juliuszint Yes, I have been thinking about this for about a year.
I usually have a main problem: to draw some kind of custom object, like a shadow, a complex object of shapes. It's always readonly object. It may have a gesture recognition, or animation, but it does not allow to get the focus and enter some text.

The hardest part is the Layout system. I would like to reuse logic from Grid, StakLayout, FlexLayour.
Therefore, Xamarin.Forms.Drawing would be very useful.
By the way, for example, a project that does this:
https://github.com/kevinbrunet/SkiaSharp.DiagramEngine

In the second part, I have 90 percent of projects that should look identical between all platforms.
I do not need native types of buttons, or input fields.
And in such a context, it would be super to have Xamarin.Forms.Platform.Skia which will allow me to do completely platform independent applications.
Here is an example of such a project:
https://github.com/AvaloniaUI/Avalonia

[charlesroddie]

@andreinitescu the size of SkiaSharp can be important (not sure, I think it's around 5MB?

Yes, when measured in 2017, although reports of 4MB more recently.

[charlesroddie]

I see two serious ways of going about this.

1. A Xamarin.Forms.Platform.Skia backend. You can select this in any platform specific project to get platform-independent views. Like other backends, this will have a Xamarin.Forms dependency, but also its weight.

2. A .Net model of layouts and views, with a SkiaSharp renderer. This could mirror Xamarin.Forms classes or be a little simpler. These can then be used in any Xamarin.Forms project, or in any platform-specific .Net project.

Either approach would

• Allow for .Net UI to target future platforms, wuch as web, relatively easily without writing new XF backends.
• Give fewer bugs, with constant behaviour across platforms less code to maintain.
• Make it easier to write cross-platform controls, with only one renderer needed.
• Make deploying on less popular platforms more viable, since any control targeting SkiaSharp would be usable on all .Net platforms.
• Make controls look the same across platforms.

These are large projects with large advantages. I prefer 2. because it would jettison all the bloat of Xamarin.Forms, which is getting unmaintainable, creating a relatively simple .Net UI layer without Xaml, CSS, Bindings, or Navigation. Those could be recreated on top as an optional package if needed. That would implement @adamped 's suggestion for Saving Xamarin.Forms.

[yurkinh]

Here is a sample of SkiaSharp backend for one platform (ios) made by Alexey Strakh

https://github.com/alexeystrakh/Xamarin.Forms.Doodle

[redradist]

I also waiting when it will be possible to useSkiaSharp renderers instead of platforms, because it more flexible solution than native renderers ...

For example with SkiaSharp renderers it would be possible to use Xamarin.Forms component in the Web, also it will make control more predictable, more testable and so on ... As for me there are lots of advantages

[redradist]

Also I think it would be better to place these views in just in separate namespace like Xamarin.Forms.Skia or Xamarin.Forms.Canvas (with different renderer libraries, not only SkiaSharp)