_This is the same pull request as https://github.com/flutter/engine/pull/50898. GitHub broke on the previous pull request so I re-created it_
This moves the logic to handle `flutter/accessibility` messages to a new type, `AccessibilityPlugin`.
Notable changes:
1. Windows app no longer crashes if it receives accessibility events it does not support
2. Windows app no longer crashes if it receives accessibility events while in headless mode
@yaakovschectman After playing around with this, I ended up using a different pattern than what what I suggested on https://github.com/flutter/engine/pull/50598#discussion_r1488728089. This message handler is simple enough that splitting into a child/base types felt like unnecessary boilerplate. The key thing is separating messaging and implementation logic, which was achieved through the `SetUp` method. Let me know what you think, and sorry for all my flip-flopping on this topic! ð
This is preparation for: https://github.com/flutter/flutter/issues/143765
Sample app for manual testing: https://github.com/flutter/flutter/issues/113059
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The Windows embedder registers "message procedures" to handle to top-level window events. These message procedures should be called in the order that they are registered.
For example, a plugin can override the embedder's app lifecycle behavior by registering a message procedure before the embedder's app lifecycle message procedure.
This did not always work as expected as the message procedures were ordered by their pointers instead of their insertion order.
Fixes https://github.com/flutter/flutter/issues/137963
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR changes the format check on CI to use the command added in
https://github.com/flutter/engine/pull/50747.
Additionally, while making this change, I noticed that the CI check was
not checking the formatting of all files, and that as a result, files
were present in the repo with incorrect formatting. I have fixed the
formatting and fixed the check to always check all files.
Improves Windows's lifecycle event for window destruction:
1. Made `FlutterWindowsView` generate the "window hidden" event when the HWND is destroyed instead of the `FlutterWindow`.
1. Before the window would submit this event using a destroyed view:
1. The `FlutterWindowsView` destructor runs to completion.
2. The view owns the window, so the `FlutterWindow` is destroyed
3. The window's destructor generates a "window hidden" event
4. The window uses the destroyed view to notify the engine of the event
2. Adds an app lifecycle integration test to verify the `resumed` and `hidden` events are sent when an app is launched and closed.
3. Removed the `FlutterWindowTest` type as it was unused
Prepares for https://github.com/flutter/flutter/issues/137267
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This makes the view own its EGL surface. This will allow us to support multiple EGL surfaces once the engine supports having multiple views.
Some notable changes:
1. EGL surface resizing logic is now entirely in `FlutterWindowsView`. Previously some resizing logic was in the `egl::Manager`, however, the view has to handle resizing failures so this unifies the logic in one place.
2. The `OnEmptyFrameGenerated` and `OnFrameGenerated` now return `false` (aka "don't present") if the surface is invalid. This simplifies the compositor as it no longer needs to check for invalid surfaces
3. This introduces a `ViewModifier` testing helper to allow overriding a view's surface. This isn't strictly necessary, tests can setup a surface by mocking several EGL methods and calling `FlutterWindowsView::CreateRenderSurface()`. However, this is verbose & heavily tied to implementation details. The `ViewModifier` avoids this boilerplate.
4. `CompositorOpenGL`'s initialization now makes the render context current without any render surfaces. Previously it also made the view's surface current, which was unnecessary.
Part of https://github.com/flutter/flutter/issues/137267
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
# Original pull request description
This introduces the `egl::Surface` and `egl::WindowSurface` types to abstract a raw `EGLSurface`. This also removes some - but not all - EGL surface logic out from `EGLManager`.
Subsequent pull requests will be necessary to:
1. Move ownership of the `egl::WindowSurface` from `egl::Manager` to `FlutterWindowsView`
2. Refactor external texture's off-screen EGL surface to use `egl::Surface`
Part of https://github.com/flutter/flutter/issues/141996
# Reland
https://github.com/flutter/engine/pull/49983 was reverted as it introduced a crash if the render surface fails to be created even though EGL was initialized successfully.
This pull request is split into the following commits:
1. c0b11be79f is the original pull request unchanged
2. 1dc7813845 is the fix: it checks a surface is valid before using it. This also adds several tests to prevent this kind of regression.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
On Windows, when using a `MouseRegion` widget to change the cursor it is not actually updated until the cursor is moved. This is because the Windows embedder only updates the `current_cursor_` field but does not actually set the cursor until the window receives the `WM_SETCURSOR` message when the mouse moves. This change makes it set the cursor immediately.
Fixesflutter/flutter#76622
This introduces the `egl::Surface` and `egl::WindowSurface` types to abstract a raw `EGLSurface`. This also removes some - but not all - EGL surface logic out from `EGLManager`.
Subsequent pull requests will be necessary to:
1. Move ownership of the `egl::WindowSurface` from `egl::Manager` to `FlutterWindowsView`
2. Refactor external texture's off-screen EGL surface to use `egl::Surface`
Part of https://github.com/flutter/flutter/issues/141996
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This is a refactoring with no semantic changes. The following types were renamed:
* `flutter::AngleSurfaceManager` to `flutter::egl::Manager`. In subsequent pull requests, this type will _create_ but not _own_ surfaces. Furthermore, this type will be split up to introduce `flutter::egl::Surface` and `flutter::egl::Context`. The manager will own the contexts and each surface will be owned by its view.
* `flutter::GlProcTable` to `flutter::egl::ProcTable`
This also introduces an `egl` directory to the Windows embedder.
Previous pull request: https://github.com/flutter/engine/pull/49895
Part of https://github.com/flutter/flutter/issues/141996
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Changes:
1. Moves surface buffer swapping from `FlutterWindowsView` to `CompositorOpenGL`
1. Renames `FlutterWindowsView::SwapBuffers` to `FlutterWindowsView::OnFramePresented`
2. Previously, if a resize was pending and the window was not visible Windows would unblock the platform thread before swapping buffers. This trick aimed to reduce the time the platform thread was blocked as swapping buffers previously waited until the v-blank. This logic was removed as swapping buffers no longer waits until the v-blank.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `EXPECT_CALL_IS_EVENT` macro used features that are not supported by Visual Studio 2022's intellisense, which results in >130 errors when editing in Visual Studio. These issues only affect the editing experience, building still works as expected.
This change reduces false errors in Visual Studio by making `EXPECT_CALL_IS_EVENT` buildable in Visual Studio.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Windows's `KeyboardManager` has several top-level helper functions. These are already wrapped in an anonymous C++ namespace, which is the C++ equivalent of the C `static` keyword.
No tests are updated as this PR is a refactoring with no semantic changes.
Â
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `FlutterWindowsView` uses the `DwmFlush` win32 API to prevent artifacts during window resizing.
Currently, the view used the `FlutterWindow` to allow mocking this win32 API. However, the window is a complex type with lots of other responsibilities. The `WindowsProcTable` is the new preferred type for mocking win32 API.
Part of https://github.com/flutter/flutter/issues/140626
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `FlutterWindowsView` needs the `DwmIsCompositionEnabled` win32 API to check whether it should block presents until the v-blank to prevent screen tearing.
Currently, the view used the `FlutterWindow` to allow mocking this win32 API. However, the window is a complex type with lots of other responsibilities. The `WindowsProcTable` is the new preferred type for mocking win32 API.
Part of https://github.com/flutter/flutter/issues/140626
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The Windows embedder has three ways to get an `HWND`:
1. `GetWindowHandle` which returns the `HWND`
2. `GetPlatformWindow` which returns the `HWND` wrapped as a `PlatformWindow`
3. `GetRenderTarget` which returns the `HWND` wrapped as a `RenderTarget`
These abstractions are no longer useful now that we removed the UWP embedder. This change removes `PlatformWindow` and `RenderTarget` and uses `HWND` directly.
This change is a refactoring with no semantic changes.
Reverts flutter/engine#48849
Initiated by: loic-sharma
This change reverts the following previous change:
Original Description:
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This migrates the Windows embedder to `FlutterCompositor` so that the engine renders off-screen to a framebuffer instead of directly onto the window's surface. This will allow us to support platform views and multiple views on Windows.
<details>
<summary>Tests...</summary>
* Verify OpenGL compositor's raster time isn't regressed and memory increase is reasonable
* Software compositor's raster time and memory isn't regressed
Test device configurations
* [x] Windows 11 (hardware acceleration enabled/disabled)
* [x] Windows Arm64 (hardware acceleration enabled/disabled)
* [x] Windows 7 (hardware acceleration enabled/disabled, DWM enabled/disabled)
</details>
Addresses https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The EGL context can only be used by a single thread at a time. Currently:
1. The platform thread uses the EGL context to configure the render surface when a `FlutterViewController` is created
2. The raster thread uses the EGL context to render
In a multi-view world, a `FlutterViewController` can be created in parallel to a rendering operation. This results in multiple threads attempting to use the EGL context in parallel, which can crash (see https://github.com/flutter/flutter/issues/137973).
This change configures the render surface on the raster thread if the raster thread exists (aka the engine is running).
Addresses https://github.com/flutter/flutter/issues/137973
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
GLES functions are resolved at runtime. This refactors how these functions are stored by introducing the `GlProcTable` abstraction.
This is a step towards switching the Windows embedder to `FlutterCompositor` rendering as the present callback will use the `GlProcTable` to render OpenGL backing stores.
Â
Part of https://github.com/flutter/flutter/issues/128904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Factors out an RAII-based class that can be used to capture std::cout, std::cerr, or technically any other std::ostream, though that's unlikely to be useful.
This makes the logic reusable but more importantly, ensures the capture is cleaned up at the end of the test.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR contains no functional changes but improves existing unit tests to reduce the number of warnings output when the tests are ran:
1. Replaced `ON_CALL` with `EXPECT_CALL` for expected method calls
2. Added some missing mocks
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
As part of eliminating the Flutter buildroot
(https://github.com/flutter/flutter/issues/67373), we are moving all
third-party dependencies from //third_party to //flutter/third_party.
Once all third-party dependencies have been migrated, tooling and config
will be moved and the buildroot will be eliminated altogether.
No tests changed because there is no semantic change to this PR. This is
simply relocating a dependency.
This refactors how high contrast is implemented on Windows:
1. Added a test to verify accessibility features are updated when a view is created. This prevents staleness issues as the Windows embedder isn't notified of accessibility changes while in headless mode.
1. Moved high contrast mode detection to `WindowsProcTable` from `FlutterWindow` to remove engine to view to window plumbing.
1. `FlutterWindow` and `FlutterWindowsEngine` now share their `WindowsProcTable` (which is used for mocking and polyfilling win32 APIs) to reduce redundant dynamic loading.
This pull request contains no functional changes.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
