FlutterBinding: Create Class And Methods Mirroring Dart::UI Library

[adamped]

Go through the Flutter Engine, and create a class and methods for everything in the dart::ui library.

[adamped]

Look here for them: https://github.com/flutter/engine/tree/master/lib/ui. E.g. if you go into UI then Window.cc

[mohachouch]

This task can be quite long. Can we generate the c# code from the dart (for all dart file) ?

I also think that we will have to modify the ".c" files.

using tonic :: DartInvokeField; using tonic :: DartState; using tonic :: StdStringToDart; using tonic :: ToDart;

Maybe we will have to rewrite the tonic library to be able to manage the conversion in C#.

[adamped]

Actually what I was planning to do in this instance, was not use the Flutter Engine at all. All the Flutter engine is doing is drawing on a Canvas. It has some threading and queuing stuff as well, but after my attempt at getting the endpoint through, then also having to try and maintain this against the base repository, it seems like a bad approach for the moment.

The rest of the stuff the Flutter engine is doing is all Dart related, and we don't need any of it. Ripping out the Dart stuff was also hard.

So the plan was, to create the dart UI. And actually we don't want to copy the window.cc, we want to copy all the .dart files in that folder. e.g. window.dart, painting.dart, but only the classes, methods, enums etc. Don't actually implement anything in there yet.

This is just the class and method signatures. Once the class and method signatures are done, then we can create numerous cases, for people to actually implement each one.

[adamped]

We could eventually have the Transpiler convert those Dart files, however they are not that big to convert, and it will hold up the rest of the project if we wait.

While those .dart files actually have some code in them, quite a few of them are just function pointers. For example with Window.dart, if you then go into the Window/window.cc file, at the bottom there is void Window::RegisterNatives and this is the list of functions in that Window.dart file that are the jump across to the C++ side.

However I don't think we should bridge across into the engine, and it would be much better to create another class (our own Engine) and wire it up to there.

[mohachouch]

Thank you for the precision

[JeroMiya]

Is this still the plan? I thought there was some discussion about another way to still use the engine.

What functionality in the engine is actually needed and not just dart bindings to skia and event processing/etc...? What would be the benefits of binding to the native code in the engine vs just implementing the public .NET interface of the engine using SkiaSharp and Xamarin Essentials?

[adamped]

Xamarin.Essentials isn't need at all, in either scenario.

The new way we were planning on doing it is building the C++ engine and creating our own C++ interop, but excluding the Dart VM related stuff from the engine.

However, we currently have a basic transpiled Dart Engine using SkiaSharp. We will continue to use that until we have a working end to end solution, then will look at replacing it.