skia engine in flutter #61
Replies: 23 comments 3 replies
-
|
The idea is amazing, Hope the .NET folks think of this seriously. |
Beta Was this translation helpful? Give feedback.
-
|
There are a lots of reason to use native controls. Accessibility for example. It is faster to get updates out when the platforms are adding new feature because you don't have to recreate them. But it would probably be possible to crrate bindings to the Flutter libraries and the create a backend to Maui based on them. But I think that should be created by the community. |
Beta Was this translation helpful? Give feedback.
-
|
This is a must. Yes, use the native controls inside your rendering just like say KendoUI, or any web library uses. But skia the whole thing and give us a web version that goes with it. No more render differently per platform problems. And honestly, it would be way better to just adopt flutter and put in C# and do to flutter what Edge is doing to Chromium which clearly has Google scared. If you put C# in and the xamarin tooling for building cross platform components along with the Xamarin emulators and best yet, gave us free online emulators and build to store for iOS so we don't need a mac at all, you'd have an enormous win. the Xamarin bottom cross platform tooling because everyone ends up writing custom per platform code which is pretty awful in Flutter and requires serious platform chops in other languages. With Xamarin, none of that is needed which would drive people to use Microsoft Flutter instead of google dart flutter while still benefiting from the flutter rendering engine. The later, because if Microsoft doesn't provide a path where developers never need a Mac, Windows is a non-starter for most end user developers and thus Windows native apps are a non-starter. If you have to have a mac anyhow, you're not going to have a mac and a pc and you'll leave windows to the web browser and windows apps die and windows becomes a glorified browser platform like Chrombooks but costing more. This has to be solved. The best way to do so is to just put ios emulators in the vs.net subscription and be done with it (or better yet vs code support). Microsoft Flutter gives you all of Google's hard work, with Xamarin and all of that tooling which completely subverts google and MS get a chance in End User development again on the back of Google's work. Win/Win. |
Beta Was this translation helpful? Give feedback.
-
|
They need to think about this and give a good reason why they choose the chosen strategy To quote Adam Pedley
|
Beta Was this translation helpful? Give feedback.
-
Why not use Flutter? |
Beta Was this translation helpful? Give feedback.
-
I do, but i love C# so much :) |
Beta Was this translation helpful? Give feedback.
-
|
Me too, Dart is ugly. |
Beta Was this translation helpful? Give feedback.
-
If the community made a Maui platform to interface with Flutter, wouldn't we just be trading iOS/Android/UWP design choices for those of Flutter? |
Beta Was this translation helpful? Give feedback.
-
I would not use it, or maybe for specific cases depending on what clients designers want. Maybe it would be a good way to create it as a Visual so you easy can apply it to specific elements. |
Beta Was this translation helpful? Give feedback.
-
|
Actually it is already implemented with Comet.Skia |
Beta Was this translation helpful? Give feedback.
-
|
Weather MS, makes bindings to flutter UI Controls, or build upon skia engine or other 2d/3d engines, the main result is one. the earlier might be faster in development but reliant on something else, and the later, might be slower in development, but non reliant on anyone else . but the end result, MS cares more on easing development, so developers use MS Cloud Functionality, and by jumping from the wrongness that java have been made with its first UI controls that depend on each platform controls and their problems, to a base model, that does not rely on any platform specifics, and just giving themes for each platform, will make its development free from any dependencies/back-word support, and really shine in the speed/graphics side. and as Adam Pedley said, big companies are having one theme for their apps, no matter what platform. thanks @yurkinh, this is a clear prof-of-concept for MS: Comet.Skia also, instead of having every release of this technology, adding more functionality, that is only adding more bindings to current device controls, MS can have its own controls, and speed up the feature additions. mobiles/devices/IoT are getting faster GPUs every year, and the UI is slow in utilizing that huge power/efficiency/fidelity, which will ease the move to VR devices, by compiling the engine to that device. and as we can see flutter in very small time, has eaten a lot of the market share, and it deserves that. But as a C# developer, a .net/.net core developer, its still much better that dart. So, MS you have this as an open source, just start the road map, and the community will help. As an Idea, MS can consider skia or the selected 2d/3d engine, as a new Device OS platform, and compile Xamarin.Forms XAML against it, and when it reaches to a good stable state, it can be the default for all Other OS(s) by a switch. Regards. |
Beta Was this translation helpful? Give feedback.
-
I think for the same reason why we have C# instead of Java. Its a choice. I have been personally using Xamarin for close to 6 years now. Xamarin was absolutely a revolution when it came out, we were able to make native UI in a cross-platform way. But as a community, we need to acknowledge that the industry have moved on, and the business don't care anymore of native looking UI for each platform. I am not claiming we should ditch the native controls. But adding skia controls would give a lot of options for our developers pick the right tool for their needs. |
Beta Was this translation helpful? Give feedback.
-
|
I have not really used much of Xamarin.Forms, as my team has mainly native iOS and Android skills so we focused on Xamarin Native (Xamarin.iOS and Xamarin.Android). I do get the point that native controls / look and feel is not really a thing anymore - however doing your own drawing (e.g. Flutter) is not the only alternative. Xamarin.Forms has adopted Material Visual which achieves more or less the same thing, keeping the benefits of accessibility and being more future proof (see: iPadOS 13.4 mouse/trackpad cursor behavior). I guess I'd be happier with expanding the Visual API to support more "design languages" (e.g. Fluent and maybe there are more) - the main challenge there being that the controls overlap surface might not be large enough. Anyhow, my point is that consistent look and feel isn't necessarily achieved only via doing your own drawing. |
Beta Was this translation helpful? Give feedback.
-
I agree with this, but making something consistent by drawing is the easier path as compared to updating the native controls per platform. |
Beta Was this translation helpful? Give feedback.
-
|
It makes a lot of sense, to create the new UI under a common 2d/3d engine. I'm guessing one of the main problems with Xamarin Forms, is mapping all the original controls, they're all moving targets. So, controls are prone to bugs, or glitches, depending on the version and OS, also Microsoft has no say on how IOS 16, or Android 20 controls will evolve. Instead of putting all that engineering work for that, they could use this opportunity to do a clean slate. And manage the whole UI, instead of using someone else UI. IMHO, this will also serve them well in the future, to unify more the UI between all platforms. They could effectively port WinUI or unify both MAUI and WinUI. As crazy as is sound, maybe DirectX or Direct3D porting is a possibility. Since our phones are no so different from the computers we use. Donno if that is possible (low level approval), but probably they can create it over OpenGL ES, and SceneKit/METAL. It could be really interesting and not only for the UI. |
Beta Was this translation helpful? Give feedback.
-
|
The whole point of Xamarin.Forms was to keep the unique look and feel of the underlying platform - and if you watch the full journey to one .NET video you will see that hasn't changed: If you want to use something that has one GUI that isn't dependant on the underlying platform then use UNO https://platform.uno |
Beta Was this translation helpful? Give feedback.
-
|
If the whole Idea of Xamarin.Forms, is to stay as is, without changing its underline renders, then, MS can begin a new parallel open source project that mimic Flutter, in making its base a 2d/3d engine, that benefit from the GPU/APU that's all around in most devices, and this will help it, in easing the unification of all platforms/OSs, and as the community is helping in shaping flutter, the same help will come in MS projects. but i still think, as Xamarin.Forms render its xaml controls to native controls, it can make the 2d/3d engine as a unified render, at least, it can start a side project as a proof of concept, and Xamarin will stay as the binder for other native OS functionality. and i agree with @maxpiva that following other vendors controls from version to another version, has its own maintenance dilemma. |
Beta Was this translation helpful? Give feedback.
-
|
There is more than one way to skin a cat. Will prefer to have stable controls and use skins if I want the native look. IMO Xamarin Forms is overengineering for the task and I think when people use it, the native look and feel is not in their list as primary, people are using it because Xamarin Forms, can leverage they software stack, maintain less code, and reuse all the work, and deploy on both android on ios, without coding native, one UI, they love it for that, and they hate it because, you know, bugs and do not work as intended (every Xamarin Forms programmer I know has issues). For me at least there is always an internal struggle between the advantages the platform gives me, and the time I'm fighting the tools and the framework to get what I want. Because let's face it, is a Frankenstein always evolving, and Xamarin playing whack a mole. As @reader-man said if the plan is stick with original controls, having a Plan B never hurts, one must think, flutter creators studied the pitfalls of the other frameworks before creating their own. |
Beta Was this translation helpful? Give feedback.
-
I think it can be done with "Visual":
|
Beta Was this translation helpful? Give feedback.
-
|
I have a Love-Hate relationship with Xamarin, will love to have the bugs and the quirks fixed. I have the opinion, they try to handle too many moving targets, without enough manpower, and not only at the UI level, but vendors also change their store API, toolchain, etc. continually. That affects the quality of the framework and tools greatly. So, or they increase the engineering power, and tame the beast. or they reduce the moving targets. Having a UI skinnable render engine, that could render current controls with Native Look & Feel, might be enough to start deprecating those franken-controls, reduce those moving targets, have a better architecture, and untie from vendor-specific limitations. |
Beta Was this translation helpful? Give feedback.
-
|
From my experience, native controls and managing the state between the native control and Xamarin.Forms control is the source of many bugs. The dreaded renderer layer :) As above, it's in a constant state of whack a mole. Having discussed this at length before, I don't think XF or MAUI should implement any Skia controls. It would be better to start a new project from scratch without the native control baggage. Personally I would love to see a Xamarin Flutter binding similar to https://github.com/adamped/xamarin.flutter It would allow the use of the .NET ecosystem, even most of the Xamarin.Essentials plugin, that doesn't use UI and many other community plugins. Companies could even use their existing .NET code bases. In terms of Skia controls, Flutter is too far ahead now. They have had years. Xamarin (the technology as a whole) is used for bringing .NET to many platforms. I believe it could focus on that mission, and use other UI frameworks, like Flutter to expand its appeal and also keep MAUI as a final maturing of XF. I would be interested to see how the .NET community reacts to a .NET Flutter. Many people get excited by it, unfortunately I never had the resources to bring it about myself. Think of F# for Flutter, its a great match up. If MS were to start a new project for cross platform UI, I think it would have to be revolutionary beyond Flutter, to take back market and mind share, which I have no idea what that kind of project would look like, at this point in time. |
Beta Was this translation helpful? Give feedback.
-
|
It’s natural for MAUI to build upon XF, because this is what we’ve got right now. I for one look forward to rearchitect a few apps using MVU/Comet and drop XAML for good. This will be “good enough” for many of my apps. I do however get a bit concerned when MS still seem to ignore the success and developer appeal of Flutter. I get worried when key employees still touts the “native UI” benefits in blogs or videos. Or when they do “now the Xamarin button has a border” celebration posts while I’ve got Flutter animations left and right in the same twitter feed. I DO understand that we need to use what we have, but this Comical Ali approach is not helping us. It has not gotten us very far since 2016. PancakeView (and now shadows) is the most important UI design “innovation” that has happened to XF in a while. That’s says a lot. Like Adam, I do think that a .NET Flutter could be a good choice for those that do not need the native approach. Help us get both with MAUI. It is good to have a choice. In the old days MS was good at “embracing and extending”. Try it again with this :) - and dare imagine how it could be used in a WASM context. |
Beta Was this translation helpful? Give feedback.
-
|
I have been reading Jetpack Compose sources these days, and now I don't think basing on Skia is not that great idea. In fact, Jetpack Compose on Android does NOT use skiko (Kotlin binding for skia) as its graphics implementation. Instead it is totally based on Why? My understanding for the reason is that bundling Skia results in bloat app size. That is a source of complaints among Flutter app devs (for example https://stackoverflow.com/questions/49064969/flutter-apps-are-too-big-in-size). XF apps are in general bigger than Flutter apps, but that does not mean bloater app size does not matter. Android graphics API implementation is based on Skia so Compose on Android can be said as "based on Skia". But that's what Xamarin.Forms does too. (Compose for Desktop does use skiko. Their app size does not matter that much compared to mobiles.) |
Beta Was this translation helpful? Give feedback.
-
|
@atsushieno Xamarin.Forms does NOT use skia - except in specific cases where a platform doesn't have an equivalent underlying control that can be used (mostly on Linux target) |
Beta Was this translation helpful? Give feedback.
-
|
Sure it doesn't. My understanding is that the entire issue thread is about it though. |
Beta Was this translation helpful? Give feedback.
-
|
This issue is related to this one xamarin/Xamarin.Forms#6877 |
Beta Was this translation helpful? Give feedback.
-
Hi,
I hope that this project starts with re-thinking of how skia is used in flutter, or other 2d/3d engines that use hardware acceleration, and does not need to use native OS controls, but simulate them.
this will minimize the OS Bindings, speed up the App, give ease for making the app run everywhere even in IoT/Web/TV/Watch later on, or on new OS(s)
We love MS Technologies, but as what happened to nokia, codac, if u don't up and running with the competition, you will be late.
and this is a new technology, that can be done from the ground up, to not have the same java ui controls mistake, of trying to use native controls and wrap them.
Regards.
Beta Was this translation helpful? Give feedback.
All reactions