Changes the interaction between the view controller and engine in both the C API and
the engine API, so that there's always an engine (as on other platforms) rather than
the engine APIs being specific to headless mode.
While adjusting the C API, this does a large cleanup:
- Renames all methods to follow a `FlutterDesktop` (prefix) + "class" name + method-style name.
E.g., `FlutterDestkopViewControllerCreate` rather than `FlutterDesktopCreateViewController`.
This makes it easier to see what functions operate on which conceptual "object" in the API.
- Reorders and groups them by the object they operate on.
Fixes https://github.com/flutter/flutter/issues/61966
Refactors the Windows embedding internals to make an engine object that
owns things associated with the engine rather than the view, and updates
the API surface to allow using the engine directly.
This is an incremental step toward both a cleaner, non-struct-based
internal structure and a finalized API surface.
- Adds a way to provide an AOT library to the C API.
- Adds app.so to the information provided by DartProject.
- Fixes the engine to only do static snapshot linking for Windows in
debug mode, not all modes, so that the provided library is used.
Engine side of https://github.com/flutter/flutter/issues/38477
This is a step toward aligning the API with macOS, and will make it easier to add the precompiled library later for release mode (since it can just be added to the project directory, without any code changes required for wrapper clients).
At the C API, uses a struct instead of individual arguments, mirroring a change that was already made on the Linux side to make the C API cleaner.
Functional changes in addition to the restructuring:
adds relative path support, as was recently added for GLFW
Uses wstring, rather than string, for paths; the conversion to UTF-8 is actually a potential problem on Windows, so pushing it into the embedding allows us the possibility of removing it later (if we can figure out a good solution at the embedder.h layer) without API breakage.
The old APIs used by the standard runner are left in place for now to avoid breaking the template on an engine roll. Once the framework template has been updated, the old API paths will be removed.
This was only necessary when the Engine had to build in multiple buildroots
where the sources where checked out at different paths relative to the
buildroot. This is no longer the case and there are already cases GN rules
have been written that mix and match variable usage with the direct
specification of the path to the Flutter sources relative to the sole buildroot.
plugin_registrar_windows.h was never fully updated for the Win32 switch,
and didn't actually compile. This introduces FlutterView (parallel to
the GLFW wrapper's FlutterWindow) as a ways of holding view-specific
functionality to expose via the plugin registrar, and moves HWND access
from the FlutterViewController to the FlutterView so that it's
available to plugins. This allows the implementation of plugins that need
access to the native HWND (e.g., moving or resizing the top-level window).
Adds simple unit tests of the new wrapper functionality, ensuring that the
files actually compile, and that the passthroughs work as expected.
This is a breaking change for Windows runners due to moving
GetNativeWindow() in the wrapper. It's not being done as a multi-stage
change (addition + deprecation + later removal) since this API is explicitly
unstable.
Adds a task runner, and exposes API to allow application-level runloops to know when they need to next call the API to process engine events. Internally, sends null events to wake up the app runloop when new events are scheduled to ensure the wait time is updated accordingly.
Fixes#36420
Makes the plugin registration structure consistent with macOS. This will
be used in generated plugin registrant files rather than a specific
implemenation class, so this helps unblock the creation of generated
registrants on Windows and Linux.
* Begin API evolution to a more native win32 API
* Child-window based hosting
* Plumb through an initial size for child window to avoid reallocated surface on start
* Windows API cleanup part 1
* Fix wrapper tests
* Ensure flutter's HWND resources are destroyed
* Final API cleanup
* Fix dynamic DPI handling
* Cleanup
* Fix a bug that was causing engine to not be shutdown correctly
* CR feedback
* auto format
* CR feedback: combine FlutterView and FlutterViewController
* The one that clang-format seems to always get wrong
* expletive
* fix sources for licesnse file
* CR Feedback
* cleanup
* Update GetNativeWindow() to return an HWND rather than a long
* fix formatting
Start work on flutter/flutter#30726 by adding an alternative win32 shell platform implementation for Windows that is not based on GLFW and that uses LIBANGLE for rendering and native win32 windowing and input. This change does not replace the GLFW implementation but rather runs side by side with it producing a secondary flutter_windows_win32.dll artifact. The following items must be added to attain parity with the GLFW implementation:
- Custom task scheduling
- Support for keyboard modifier keys
- Async texture uploads
- Correct high DPI handling on Windows versions < 1703
and will be added in subsequent changes.
