Feedback

[jsuarezruiz]

The goal of this library is to have drawn controls with Cupertino, Fluent and Material support for Android, iOS, macOS, Windows and Linux. The idea is to have high performance pixel perfect controls offering the same rendering and behavior across platforms. The list of initially supported controls will be the controls included in Xamarin.Forms Visual with the same properties and events: Button, Slider, Entry, etc.

Your feedback is welcome!

[saint4eva]

@jsuarezruiz Firstly, you are doing a nice work - keep it up. Could you produce a NuGet package so we can test the library? Thanks

[timahrentlov]

I like it! How easy will it be to extend or change the controls compared to the handler/renderer approach?

It would also be nice to get a couple of navigation controls that in combination with the MVU paradigm could be used to implement a flutter-esque SPA architecture that does not use the current XF page concept. I'm thinking of drawn replacements for NavigationPage, TabPage, Flyout page + new ones that emulates modal popups, hero navigations, better custom animation, etc.

As I see it, it is only important to make sure that we can still use high-performance native control abstractions like CollectionViews and CarouselViews, or use native controls that somehow relies on important platform features like accessibility, special keyboards, maps, etc. But there should be no reason why these native abstractions can't live in some new drawn navigational framework. I also suspect that this will be a whole lot easier to port to Linux and WASM :)

[webprofusion-chrisc]

Hi! The gold standard for cross platform is when you can do the major platforms and web. Uno tackles this with WASM, could these controls be made to work?

Very excited to see drawn controls. Accessibility is obviously the priority, followed by functionality, performance (and style-ability?)

[jsuarezruiz]

Thank you all for the feedback.

@saint4eva Having a simple way to test is definitely a better way to get feedback. For now, you can sync the repository and try the sample. Later we can generate NuGet packages on GitHub. It will be when progressing more with https://github.com/dotnet/GraphicsControls/blob/master/STATUS.md

@timahrentlov I have updated the README with an example of how it will be to create a drawn control or modify an existing control. Will include specific examples of custom controls or an existing control by customizing how to draw any of the layers.

The initial idea is to have all the controls available in Visual Xamarin.Forms:

• ActivityIndicator
• Button
• CheckBox
• DatePicker
• Editor
• Entry
• Frame
• Picker
• ProgressBar
• Slider
• Stepper
• TimePicker

Later, yes, more possibilities can be added.

As for reaching new platforms, yes, it makes it easier. Using native controls, require a renderer to map each abstract view with a native control. In this case you only need to decide how to render on the platform (Example: Linux can use Cairo, SkiaSharp) and create the renderer for the Canvas used on that platform.

@webprofusion-chrisc These drawn controls are based on System.Graphics. In System.Graphics there are implementations for Blazor (WebGL) https://github.com/dotnet/System.Graphics/tree/5754007eb4d52cf1dc6dbdb25a44d159f97782d8/src/System.Graphics.Blazor It could be possible.

Priorities include performance, accessibility, and customization capabilities among others.

[Cfun1]

I really enjoyed the concept because from simple things + your imagination you can build amazing things, and at the same time you don't loose performance. Also I enjoyed the video where you explained step by step the concept and how to build a control you made the task fun, it is very helpful and wish to see more maybe a part 2.

[charlesroddie]

We want this!

This is a great project. There is a huge demand for platform-independent rendering which is always blocked by the history of Xamarin. This library could end up becoming the best option for the majority of XF/Maui developers, allowing them to:

• Avoid things looking different on different platforms
• Avoid platform-dependent bugs
• Depend on a higher quality repo since contributions improve all platforms and there isn't the noise of some UI doesn't work on some platform.
• Support further platforms easily e.g. the web

Suggestion: focus on plain manually-styled controls first

Cupertino, Fluent and Material

We would not want any automatic styling: only plain styling unless indicated otherwise by specifying explicit properties. Presumably these design systems are optional things at the periphery of this library? I would highly recommend working getting feedback on the standard controls until they are very polished, before splitting off users who want to use one of these design systems, to avoid similar problems to those above (design-system-dependent bugs, noise of managing x controls on y design systems...).

[Speculative] How far can this go?

In theory Xamarin.Forms/MAUI View objects render to/are handled by GraphicsControls objects, which then render to native graphics. I wonder if XF/MAUI could then be taken out completely, and we could work directly with GraphicsControls?

[AliShahesmaeili]

@jsuarezruiz Hi, good work! Neumorphism is a new design style! Please consider this style as well Some UI UX with Neumorphic

[nerocui]

This is such great work!

I was researching the other day about things like this. I know that MAUI currently has no plan to target web, but this could change so much. A lot of web apps are slow and heavy, but if this could work with WebGPU (which is much faster then WebGL) and Web Assembly, web apps could be running at near native speed. And people can finally stop using Electron just because it aligns the code base for all platforms (except mobile, but THIS does all platforms including mobile, so it's even better in that regard).

So my question is: Could this work with WebGPU and Web Assembly? MAUI and Comet are all trying to provide as much choice as possible (in terms of how controls are rendered), so experimenting on those frameworks may need to consider/implement a lot before seeing any result. So I think it could almost be beneficial to assemble some building blocks from either MAUI or Comet to have a drawn control only framework where it can target any platform including (and also most importantly) web.

Flutter has gained a lot of popularity because of this (among other reasons), but I think this could be something for the .NET ecosystem. And WebGPU running on Web Assembly could be much faster than transpiling to JavaScript (which is what Flutter does I think)

[KSemenenko]

We also need some gestures and LetterSpacing https://docs.microsoft.com/en-us/dotnet/api/skiasharp.skpaint.textscalex?view=skiasharp-1.68.1#SkiaSharp_SKPaint_TextScaleX

var paint = new SKPaint
{
    TextSize = 64.0f,
    IsAntialias = true,
    Color = new SKColor(136, 136, 136),
    TextScaleX = 1.5f
};

[danardelean]

This library should be officially be supported by Microsoft . I know that it is a lot of work but with just 2 contributors ( Javier is one and the other 3 looking at the commits still fall behind so counting as 2) this library is already really good. I don't think we need design parity perfection (even if it would be welcomed) but the benefits on performance side would make it worth the investment. For both Android and iOS the way Xamarin/.Net for iOs and Android drawing the controls in the runtime where we are coding (.Net) and not having proxy's to the native one (reference count or worst Java GC) should bring a real boost in performance.

[kerberosargos]

Hello when will you create nuget package?

[jsuarezruiz]

@kerberosargos By implementing animations and other small pending details. I would say that in the next few weeks the first package will be ready.

[kerberosargos]

@jsuarezruiz Thank you for your effort.

[listepo]

@jsuarezruiz How to add prefix and suffix text for Entry(Material)? Is it possible? Or need to create a new control?

[Martinn2]

I really like the idea of drawn controls! Hopefully more effort will come here in future. I am not sure how layouting of controls will be solved. If I want to use this package on native platform and web, I cannot use StackLayout and others as they are part of .NET MAUI right? So if we want this to be independent of MAUI we need to handle layouting as well. Is this also the target of this project?

[jsuarezruiz]

@listepo Could be possible but not already implemented. @Martinn2 Yes, at the moment is using the .NET MAUI Layouts, so have some dependencies for now. The initial goal is to have solid, stable, high-performance, easy-to-customize pixel perfect controls. After complete this first milestone (Cupertino, Material and Fluent), other options could come. And using SkiaSharp in Linux, WebGL for the web etc would be an option and the point you indicate should be covered first.

[KSemenenko]

I love this library. My UIs are 99% the same between platforms. I did something similar for myself a couple of years ago, but it was only for some tasks. And I really liked that approach. I don't want to bother with the native UI when I don't need it. Especially complex shadows. Especially complex elements.

It would also be great to be able to create my complex components. Which sometimes I need to draw from primitives and sometimes I need to use Layouts and it would be nice to have one UI component as a result.

For example: 9path button. As we understand it is made from a Grid divided into 3 rows and 3 collumns. And as I understand in the current implementation I will really have a Grid and 9 elements. And I would also like the ability to combine this into one View (or Canvas). That is when these Grids will only exist in the drawing math of the Skia control. but for the application it will just be one Skia Canvas.

<GraphicsGrid>
    <GraphicsGrid.Rows>
       ...
    </GraphicsGrid.Rows>

   <Rect Grid.Row="1" />
   <Rect Grid.Row="2" />
   <Rect Grid.Row="3" />
   <Button Grid.Row="4"/>

</GraphicsGrid>

I think that such a thing would increase the performance. And open up the possibility to create your own lists and any other Skia-based components. And that way we can make our answer to Fluiter.

[IvoKrugers]

I love this!! It is so often that we need to tweak the UI to get a consistent experience across platforms. One question @jsuarezruiz, can I run the sample with VS4Mac?

[jsuarezruiz]

@IvoKrugers Using https://visualstudio.microsoft.com/vs/mac/preview/ you could get to compile etc, although details are still missing to have the same level as in Windows.

[charlesroddie]

@KSemenenko And I would also like the ability to combine this into one View (or Canvas).

https://github.com/wouterst79/FluidSharp (@wouterst79) does this and we are considering using this or doing something similar.

I just wrote a SkiaSharp grid which has reduced loading time of an 800x20 grid (a univeristy markbook) from 210s to 0.7s.

[jsuarezruiz]

@charlesroddie It looks great!. If you want, can collaborate by creating something similar but using Maui Graphics in this case here.

[andreinitescu]

There are two main questions I have about this approach:

• Accessibility

• Extensive performance comparison compared to the native controls (for example compare the time to display a drawn Button to a native Button) on all the platforms (because in the context of cross-platform of at least iOS and Android, it doesn't matter if it works well on iOS if it's bad on Android, or viceversa)

It won't suffice to throw some simple performance comparisons, the difference will be very small with a single control, but it's very different when there's 20 labels, buttons, images, all using layout controls (Grid, StackLayout, etc.), etc. Also, take into account things like alignment (you want text on a Button to be left aligned, etc.) or gradients on different button states.

There's also another thing: With custom drawn controls you don't get the native support for different features. If Apple or Google wants to have some special feature on some controls, they will never be available for these drawn controls or if some it will be possible, it will be complicated to implement it.

[jsuarezruiz]

There are two main questions I have about this approach:

• Accessibility
• Extensive performance comparison compared to the native controls (for example compare the time to display a drawn Button to a native Button) on all the platforms (because in the context of cross-platform of at least iOS and Android, it doesn't matter if it works well on iOS if it's bad on Android, or viceversa)

It won't suffice to throw some simple performance comparisons, the difference will be very small with a single control, but it's very different when there's 20 labels, buttons, images, all using layout controls (Grid, StackLayout, etc.), etc. Also, take into account things like alignment (you want text on a Button to be left aligned, etc.) or gradients on different button states.

There's also another thing: With custom drawn controls you don't get the native support for different features. If Apple or Google wants to have some special feature on some controls, they will never be available for these drawn controls or if some it will be possible, it will be complicated to implement it.

All the drawn controls use a native canvas that have a native view as parent. We already map the a11y options related with the screen reader taking advantage of that native part. High contrast colors, for example, would use another totally different implementation, it would rather detect the use of high contrast (today, for example, the change of theme is detected) and adjust colors, etc.

About performance, there are differences depending on the control. In general the difference between loading a page with a single native control or a single drawn one is low. The difference is noticeable with 100 or 1000 controls for example. Loading 100 Material Entries using a Compatibility Custom Renderer vs drawing (the entry using Handler reduces the difference).

At the UI level everything can be adapted in some way. At the behavioral level there are more complex aspects or would require more effort. For that reason, there are also hybrid control implementations. These are controls where the UI is drawn but has parts depending on native. Example: Entry: draw background, icons, etc but when selecting text and allowing copy or paste content, use native. https://github.com/dotnet/Microsoft.Maui.Graphics.Controls/blob/main/src/GraphicsControls/Handlers/MixedGraphicsControlHandler.cs

[andreinitescu]

At the behavioral level there are more complex aspects or would require more effort. For that reason, there are also hybrid control implementations. These are controls where the UI is drawn but has parts depending on native. Example: Entry: draw background, icons, etc but when selecting text and allowing copy or paste content, use native.

Yes, that's the kind of big challenges I was referring to, which on long term need a lot of maintenance.

[wouterst79]

it may be time to set up a call with a few of us to show you guys some of the things the fluidsharp library can do and discuss how this might help your efforts

[jsuarezruiz]

@wouterst79 Sure thing, just write me an email and we can organize a meeting :)

[wouterst79]

i've sent a mail, and have updated my e-mail on github just in case

[jsuarezruiz]

@wouterst79 Sent an email with a proposal for a meeting, let me know if that is fine for you :)

[wouterst79]

Hey Javier, it was nice meeting with you today!

I have summarized the user (developer) benefits of using "FluidSharp" as follows in the past:

• A high performance mobile first multi-platform UI layout framework.
• Built on top of Skia, just like Chrome and Flutter.
• Integrates with Xamarin Forms, Xamarin.Android, Xamarin.iOS, WinFormsCore and more.
• Use it as a view, or to draw your whole app (including navigation containers).
• Edit and continue support for a better "hot reload" experience.
• Full multi-language and RTL support.
• Lots of in-built widgets (that are drawn by the framework) - Textbox uses native controls.
• Great for both simple, and complex views like grids and search results.
• Easy to extend with your own layouts; make any UI that you can imagine!

As discussed, from my perspective, there's definitely advantages of drawing controls instead of relying on the OS:

• Much better performance (possible)!
• Much richer UI
• Better cross-platform parity (and better Windows support)
• Faster UI development turn-around
• Better UI thread management
• Reduces some of the problems of XAML (full "binding" breakpoint support)
• Less black-box code
• Good migration path for existing C# based applications.

I'll look forward to discussing some of these benefits with the larger product team.

[RaulRG]

This is such a great project. I do hope this will be the future of MAUI. Drawing the controls is the way to go and would enable such "crazy" things like having a Web version of MAUI using WebAssembly. Skia is already available as a wasm library and at least in theory such a thing would be possible. Kind of hybrid between Blazor and MAUI. HUGE potential!