Windows Support about flutter-desktop-embedding HOT 67 CLOSED

It could really be a game changer for company internal applications!

from flutter-desktop-embedding.

The GLFW Windows implementation is landed! 🎉 Thanks to @CallumIddon, as well as to everyone who provided information and feedback during all the Windows discussion.

I'm closing this out now, with #101 tracking the next stage implementation, so interested parties will want to follow that issue.

from flutter-desktop-embedding.

flutter/engine#4730 (comment)

Looks like the Engine builds on Windows now.

from flutter-desktop-embedding.

I'll experiment with the UWP stuff over the long weekend. Maybe I can draw something onto the screen with angle, but my c++ knowledge is limited.

from flutter-desktop-embedding.

@slightfoot I was able to download the binaries per your instructions above and at least get the dll to load and give me a bad configuration message in win32 which isn't surprising as I didn't attempt to get Angle up yet ;-). But off to a start. I have other pieces in different places, will start bringing them together.

from flutter-desktop-embedding.

Agree. This is huge.

The only other options now are:

Qt

Xaml which uses skia under the hood hilariously.

Electron / webview.

from flutter-desktop-embedding.

Since linux version is based on glfw3 (which is also available on windows) there's a possibility that it would work also on windows. I don't have access to windows machine, so you can try it yourselves 😉

from flutter-desktop-embedding.

I'd definitely start with trying to use the prebuilt engine, although if there are engine issues on Windows having a build may become necessary to debug/fix.

In theory you should be able to run flutter-desktop-embedding/tools/dart_tools/bin/update_flutter_engine.dart on Windows to get the right version for your Flutter tree. In practice it hasn't been run on Windows yet, so if you run into issues with it let me know!

from flutter-desktop-embedding.

The GLFW version is temporary; the goal is to have all platforms have something closer to the current macOS level of integration where the Flutter content can be an arbitrary view within the native application.

A temporary GLFW build for Windows would be fine as well, but that wouldn't be the full implementation.

from flutter-desktop-embedding.

For Windows the ideal solution would use Windows APIs directly.

from flutter-desktop-embedding.

There are 3 options to embed the engine on Windows

• Win32 API

The classic Win32 API could be used. This is the most powerful Windows API. But it's old, hard to use, is written in old C style. And not future proof (no UWP support).

• .Net API

Still as powerful as Win32. C++ API. But has additional install steps (user needs to install .Net redistributable packages) and does also not run on UWP.

• Universal Windows Platform API

I think the focus should be on this. The API is future proof, easy to use, state of the art (with markup language and touch support) and runs on all Windows 10 Platforms (Xbox One etc.). Microsoft itself is converting its desktop apps to this. The problem is MS is using a costum C++ dialect and I'm not sure how hard it would be to integrate the flutter engine.

See: https://docs.microsoft.com/windows/uwp/get-started/create-a-basic-windows-10-app-in-cpp

from flutter-desktop-embedding.

@b-strauss did you get anywhere? I work on the compositor team at microsoft and am familiar with what we’re doing with c++/winrt which is the future for native dev. @stuartmorgan woudl love to chat about taking your above MVP and seeing if we can run with that.

from flutter-desktop-embedding.

OK I'll try building the engine on windows myself and see if I can get past that. I think the best solution would likely be Angle + C++/WinRT with both a desktop and UWP host. Have been playing with some of the new hosting API's my team builds as seen here https://twitter.com/Clarkezone/status/1005658900115308545 and those might be applicable here as well.

from flutter-desktop-embedding.

@clarkezone Just a few days ago I thought I'd give this a go. The build bot now builds windows embedder DLL files. I used the guide and linked example to try and get a version on windows working but I didn't have much luck. Looks like a crash in the DLL caused during DllMain execution because it crashes before my code starts. Check it out and perhaps you have better luck. Post back your results.. I'm very interested.

https://groups.google.com/forum/#!topic/flutter-desktop-embedding-dev/MX1Scz3ITAs
https://github.com/flutter/engine/wiki/Custom-Flutter-Engine-Embedders

from flutter-desktop-embedding.

I have a basic version working on Windows that implements rendering and mouse events based on #12 with instructions on getting up and running on Windows over at https://github.com/CallumIddon/flutter-desktop-embedding/tree/GLFW-Windows/.
Should I file a PR?

from flutter-desktop-embedding.

Seems to work fine, and flutter_gallery's example works too! Had to add whatever was done in the "example":

import 'package:flutter/foundation.dart'
    show debugDefaultTargetPlatformOverride;

void main() {
  // Desktop platforms are not recognized as valid targets by
  // Flutter; force a specific target to prevent exceptions.
  debugDefaultTargetPlatformOverride = TargetPlatform.fuchsia;
...

https://drive.google.com/open?id=1_DPr9kmoy3sGCCXb6WNAUoBkI6DcNHe4 (45mb zipped file with the gallery example).

from flutter-desktop-embedding.

GTK is a possibility that's currently being investigated. Now tracked as issue #23 since I hadn't filed it yet.

from flutter-desktop-embedding.

I don't have a Windows development background, so I don't have an informed opinion about whether C++ or C# is dominant enough within the domain to make it a clear choice for the API surface. I'm happy to hear arguments from people with significant Windows experience.

(Absent any clear consensus for C# I would lean toward C++ for a few reasons.)

from flutter-desktop-embedding.

C++ would allow sharing code across platforms in the plugin implementations. While this may not be a large surface area, there is at least some code in the TextInput area that would benefit from a shared model class. Also, the Flutter embedding API is in C, so use of it from C++ is straightforward; I'm not sure about the situation for C#.

That said, like Stuart I do not have a deep Windows development background, so these are just surface observations.

from flutter-desktop-embedding.

Would using SDL be ok ?

I only ask because i have been playing around with a FLutter Desktop that uses SDL.

from flutter-desktop-embedding.

This seems like the supported to support windows

https://github.com/Microsoft/cppwinrt

UPDATE:
they have moved the code into the Windows 10 SDK now.
See here for more info: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/index

from flutter-desktop-embedding.

@gedw99

You have to be careful with the terminology here.

There was/is C++/CX which is a C++ language extension to be used for UWP app development.

The new thing now is C++/WinRT which is a new C++ "language projection" based on C++17 to be used for UWP app development (not to be confused with the actual Windows Runtime the platform runtime or WindowsRT a discontinued Windows mobile variant).

IMHO we should be using the things Microsoft suggests, which is:

The Universal Windows Platform API (UWP) for cross platform support together with C++/WinRT.

https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/

To quote Microsoft:

There is not a roadmap for deprecation of C++/CX. However, all of our conversations with customers shows usage to be very low. We’re investing heavily in C++/WinRT and we expect that it will provide a much better experience than C++/CX.

https://blogs.msdn.microsoft.com/vcblog/2017/11/01/cppwinrt-is-now-included-the-windows-sdk/

Skia seems to have some level of support:
https://skia.googlesource.com/third_party/sdl/+/master/docs/README-winrt.md

from flutter-desktop-embedding.

Great! I'm happy to help on the C++ aspects; feel free to ping me on a work-in-progress branch (no matter how rough or incomplete) with questions.

from flutter-desktop-embedding.

Here's the windows-embedder library as of:
flutter/engine@63e2071

https://storage.googleapis.com/flutter_infra/flutter/63e2071da8bd4400addab933f32b9e8728702c1b/windows-x64/windows-x64-embedder.zip

from flutter-desktop-embedding.

@clarkezone build instructions are here:

https://github.com/flutter/engine/blob/master/CONTRIBUTING.md

from flutter-desktop-embedding.

@stuartmorgan what would be 'closer' on linux site then?

from flutter-desktop-embedding.

What would be closer on the Windows OS then ?

from flutter-desktop-embedding.

@stuartmorgan regarding the question above.

from flutter-desktop-embedding.

from flutter-desktop-embedding.

from flutter-desktop-embedding.

There have discussion about code reuse across all desktops to replace GLFW and for the plugins.

This might be a good example of it.
https://github.com/zserge/webview

Its a webview for all desktops that is written in C, and has wrappers from golang , rust and python ( separate repo).

It also handles window aspects.
It might be a decent reference point in general in order to be able to have the framework code and plugins all written in portable C.

from flutter-desktop-embedding.

@gedw99 I think there are diffrent. In flutter, the Paint is base. and Web has not the replacement.

from flutter-desktop-embedding.

Its a webview for all desktops that is written in C [...] It might be a decent reference point in general in order to be able to have the framework code [...] all written in portable C.

It's not written in portable C. It's a C wrapper around GTK-specific code on Linux, Win32 code on Windows, and ObjC Cocoa on macOS.

It also handles window aspects.

Yes, by implementing them using platform-specific toolkits, just like this project is doing on the platforms that have been implemented.

What's missing for a Windows implementation of this project is not a conceptual understanding of what needs to be written or how to write it, it's someone actually doing the work.

from flutter-desktop-embedding.

Good points and thanks for the clarification. I am not good enough at this level or coding to do the windows work. Wish I was.

I hope someone that does have the skills on Windows picks this up. The Mac and Linux versions are amazing to use

from flutter-desktop-embedding.

@b-strauss Can you link to any example code using the costum c++ UWP api ?
Maybe some decent examples on github for instance.
For example this has touch and mouse and keyboard combined.
https://github.com/Microsoft/Windows-universal-samples/tree/master/Samples/Simple3DGameXaml

I tend to agree. Also with the Windows Store becoming the only way to deploy (unless you ask a user to side load) you basically have no choice as a developer but to embrace the UWP.

There is Winrt, which is now part of the latest Windows 10 SDK. But i have no idea what support for UWP it has.
This does shine some light on it though: microsoft/Windows-universal-samples#851

from flutter-desktop-embedding.

@b-strauss
Thanks for the clarification.

The last to link to the SKIA winrt support is a big bonus !!!
Also i noticed it say SDL applications. This would be great because SDL is quite easy to work with i find.
What confuses me is that in the Mac and linux ports in this repo there is no SDL. Its like a split brain with mac and linux and windows being built on a different bridging layer

I am hoping that the team start on this. My problem right now is that there is no basic build for windows yet or even architectural clarification ( but winrt looks like the one to me).
Once some meat is on the bones i can help i feel.

from flutter-desktop-embedding.

My problem right now is that there is no basic build for windows yet or even architectural clarification

As mentioned above, I would be happy to review and land an initial basic build separate from a decision about long-term architecture (as with Linux and the GLFW implementation). Several people indicated interest on the mailing list in helping with a Windows implementation, but so far nobody has sent any PRs or otherwise followed up.

from flutter-desktop-embedding.

from flutter-desktop-embedding.

Or GLFW, or any other workable interim solution. A simple throw-away implementation (enough to support drawing and mouse events) that lets people try it out on Windows would be useful to have until there's a full implementation.

from flutter-desktop-embedding.

from flutter-desktop-embedding.

Just a note on OpenGL and desktop applications: with the Nvidia drivers (under assuming Nvidia card) these do not work properly with Remote Desktop (Intel's for example is fine, maybe AMD too). Off course there is Google angle, but it wraps GLES not OpenGL (or maybe I have outdated information). Just FYI

from flutter-desktop-embedding.

Yeah, I would like to give it a look as well, got some experience in cross-platform 3D software (games). I am however missing something like a list of TODOs. On the one hand you have the example GLFW Embedder, on the other the ticket is open. So what exactly is needed to consider Flutter running on Windows? Do we have a list bunch tests to turn green, or do we need to write them as well?

from flutter-desktop-embedding.

@njskalski The GLFW embedder would just be a sandbox or playground to show basic things. A complete solution involves getting flutter onto the Universal Windows Platform with C++/WinRT.

This would include:

• making Skia run on UWP; this requires some sort of bridge because UWP has no native opengl support; something like angle could be used
• making the flutter engine run on UWP
• creating a flutter XAML view in UWP that receives the native events (pointerevents, etc.)

from flutter-desktop-embedding.

On the one hand you have the example GLFW Embedder, on the other the ticket is open

We have it on Linux; there's currently nothing set up in the repository that builds on Windows.

The minimum to close this issue would be to have a windows/ directory that contains an embedder (even if it's essentially identical to the original GLFW Linux implementation) for example_flutter, including build files and instructions.

If we get to that point, I'll close this out and track a full (UWP or Win32) implementation in another issue. (But if we skip directly to a UWP initial implementation, that's great too.)

from flutter-desktop-embedding.

I had problems with setting up the engine (gclient errors). I did not have time to continue since then. 😞

from flutter-desktop-embedding.

See https://groups.google.com/forum/#!topic/flutter-dev/IyXM4D7OKyg for details.

from flutter-desktop-embedding.

Sounds great. I didn't know C++/WinRT could be used without UWP. What would be the platform then? Win32 or .Net?

from flutter-desktop-embedding.

Sounds great. I didn't know C++/WinRT could be used without UWP. What would be the platform then? Win32 or .Net?

@b-strauss yes indeed ;-) its win32. BTW dont suppose you can point me at instructions to build flutter engine on windows?

_{Sent with GitHawk}

from flutter-desktop-embedding.

Here's the windows-embedder library as of: ...

@slightfoot thx will take a look

_{Sent with GitHawk}

from flutter-desktop-embedding.

I added some initial glfw code based on this. I'm using visual studio community edition. The thing compiles and starts to run, but I'm getting an error.

https://github.com/b-strauss/flutter-desktop-embedding/tree/feature/glfw/windows-glfw

from flutter-desktop-embedding.

I don't know if it's what's causing the crash, but that code is using the old .flx format, which as far as I know isn't buildable with any version of Flutter that has a prebuilt Windows engine. So I strongly suspect that you are either using an old Flutter tree that doesn't match the engine version, or you're pointing the engine at a file that doesn't exist (or is very stale if your example app was build with flx at some point in the past).

You'll want to change that to "build/flutter_assets"; if it's not the cause of the current crash, it's something that will cause problems later.

from flutter-desktop-embedding.

I'm still getting the same error. I suspect the code is probably just to old. Maybe someone can take a look?

https://github.com/b-strauss/flutter-desktop-embedding/tree/feature/glfw/windows_glfw

I updated the build commands. People should be able to build this now after downloading the needed dll files. See readme.txt for more info.

from flutter-desktop-embedding.

Your readme is giving a precise engine version but doesn't say anything about the Flutter version you are using; that's a really good way to get a mismatch. The engine version must match the version specified in your Flutter tree.

Is there a reason you aren't using the script to download the right version automatically?

from flutter-desktop-embedding.

Also, you're still not passing the flutter_assets path to the engine; you removed the flx path, but didn't add the correct asset path.

You need to have run 'flutter build bundle' in the directory of the Flutter application you are trying to load, and you need to pass the resulting build/flutter_assets directory as the assets_path in the struct.

from flutter-desktop-embedding.

Per my last comment to @slightfoot, the flutter binary loads fine from a win32 context. I just tried loading it from an appcontainer context and getting an AV/exception thrown in the flutter startup code in this file: os_thread_win.cc.. I'm not seeing that in the engine source tree unless I'm missing something. Looking at the disassembly looks like a lock / semaphore is not getting acquired correctly.

from flutter-desktop-embedding.

From my local engine checkout, it looks like that's coming from a Dart dependency:
https://dart.googlesource.com/sdk.git/+/master/runtime/vm/os_thread_win.cc

from flutter-desktop-embedding.

@clarkezone that was the same issue I had. I think the next option is to attempt to build the engine.

from flutter-desktop-embedding.

In the process of integrating Angle with the win32 version, I'm now hitting the same issue there as well.. interestingly the call to D3D11CreateDevice is what's causing it in this case. @slightfoot any insights / pointers / learnings you can share? Next step is to build the engine and attempt to debug.

from flutter-desktop-embedding.

@stuartmorgan so now I can build the engine (yea) I commented out the body of OnDartThreadExit and everything is working well enough to make forward progress. Haven't figured out where threadexit is being hooked nor what the root cause is for the null reference exception in rundestructors.. maybe later :-)

from flutter-desktop-embedding.

Awesome, please do! As I mentioned above, I'm happy to have an initial implementation in the tree ASAP even if it will likely be replaced soon by a more extensible version.

from flutter-desktop-embedding.

from flutter-desktop-embedding.

@clarkezone I'm getting an error when running the code with Visual Studio 2017 Community Edition. Do I need another Visual Studio Version? Thanks.

from flutter-desktop-embedding.

@b-strauss The currently landed code, which it looks like is what you are running there, is @CallumIddon's implementation, not the code @clarkezone has been working on (which is now tracked in #101)

See the discussion at the end of #87; I'm also unable to run it from VS (although the error I saw was different), but it works for me from the command line. I'd suggest seeing if the same is true for you.

Either way, please file a new bug for your issue so it can be tracked.

from flutter-desktop-embedding.

@b-strauss should be fixed in #106. If you could test it and let me know in that pull if it works or not it would be greatly appreciated.

from flutter-desktop-embedding.

TLDR - Delayloading (/DELAYLOAD:flutter_engine.dll) solves the crashing issue while debugging in Visual Studio.

What happens is that in the debugger, or maybe due to other circumstances, some thread exited (happened to be from the NVIDIA drivers), which is normal and expected, but Dart, more specifically flutter_engine.dll has established this "DllMain"-like handler (for lack of better explanation): https://github.com/dart-lang/sdk/blob/master/runtime/vm/os_thread_win.cc#L712 - e.g.

#pragma data_seg(".CRT$XLB")
PIMAGE_TLS_CALLBACK p_thread_callback_dart = OnDartThreadExit;

and

void NTAPI OnDartThreadExit(PVOID module, DWORD reason, PVOID reserved) {
  if (!dart::private_flag_windows_run_tls_destructors) {
    return;
  }
  // On XP SP0 & SP1, the DLL_PROCESS_ATTACH is never seen. It is sent on SP2+
  // and on W2K and W2K3. So don't assume it is sent.
  if (DLL_THREAD_DETACH == reason || DLL_PROCESS_DETACH == reason) {
    dart::ThreadLocalData::RunDestructors();
    dart::MonitorWaitData::ThreadExit();
  }
}

Now if this handler is called with DLL_THREAD_DETACH reason (as it happened with NVIDIA's driver), then it'll try to:

    dart::ThreadLocalData::RunDestructors();
    dart::MonitorWaitData::ThreadExit();

but Dart::InitOnce (https://github.com/dart-lang/sdk/blob/master/runtime/vm/dart.cc#L111) wasn't yet called, which would later call "OS::InitOnce();" then call (for os_win.cc) "ThreadLocalData::InitOnce" which would've initialzied two globals (mutex_ and thread_locals_) which were actually NULL when this happened.

Or maybe somewhat better order of initialization...

from flutter-desktop-embedding.

from flutter-desktop-embedding.

Oh, sorry - should've checked your messages above. I've run into similar issue with https://github.com/ds84182/flutter_sdl and had to fix it, but now that I saw the change in the main line decided to give it a try.

from flutter-desktop-embedding.