- 31 May, 2023 1 commit
-
-
Loïc Sharma authored
Address Tong's feedback here: https://github.com/flutter/flutter/issues/127695#issuecomment-1564884872 Follow-up to: https://github.com/flutter/flutter/pull/127046
-
- 19 May, 2023 1 commit
-
-
Loïc Sharma authored
## Background The Windows runner has a race at startup: 1. **Platform thread**: creates a hidden window 2. **Platform thread**: launches the Flutter engine 3. **UI/Raster threads**: renders the first frame 4. **Platform thread**: Registers a callback to show the window once the next frame has been rendered. Steps 3 and 4 happen in parallel and it is possible for step 3 to complete before step 4 starts. In this scenario, the next frame callback is never called and the window is never shown. As a result the `windows_startup_test`'s test, which [verifies that the "show window" callback is called](https://github.com/flutter/flutter/blob/1f09a8662dad3bb1959b24e9124e05e2b9dbff1d/dev/integration_tests/windows_startup_test/windows/runner/flutter_window.cpp#L60-L64), can flake if the first frame is rendered before the show window callback has been registered. ## Solution This change makes the runner schedule a frame after it registers the next frame callback. If step 3 hasn't completed yet, this no-ops as a frame is already scheduled. If step 3 has already completed, a new frame will be rendered, which will call the next frame callback and show the window. Part of https://github.com/flutter/flutter/issues/119415 See this thread for alternatives that were considered: https://github.com/flutter/engine/pull/42061#issuecomment-1550080722
-
- 08 Dec, 2022 1 commit
-
-
Loïc Sharma authored
Adds a test to verify the console output of `flutter run --release` on Windows. Part of: https://github.com/flutter/flutter/issues/111577
-
- 30 Aug, 2022 1 commit
-
-
Loïc Sharma authored
-
- 30 Jun, 2022 1 commit
-
-
stuartmorgan authored
-
- 07 Jun, 2021 1 commit
-
-
Jason Simmons authored
-
- 28 Sep, 2020 1 commit
-
-
Jonah Williams authored
Check in linux and windows platform code now that they are stable, so that we could use in devicelab in the future. Removed the ICO from the windows example to avoid analysis check, and since it won't be important for benchmarking or UI tests
-
- 17 Sep, 2020 1 commit
-
-
stuartmorgan authored
The engine now has an explicit API for system font changes, rather than expecting the WM_FONTCHANGE message to be forwarded to the Flutter view.
-
- 10 Sep, 2020 1 commit
-
-
stuartmorgan authored
-
- 31 Aug, 2020 1 commit
-
-
James Clarke authored
-
- 21 Aug, 2020 1 commit
-
-
stuartmorgan authored
This wires up the new WindowProc delegation system that allows plugins to handle top-level window messages (e.g., to control resize behavior). Fixes #53168
-
- 13 Aug, 2020 1 commit
-
-
stuartmorgan authored
-
- 06 Apr, 2020 1 commit
-
-
stuartmorgan authored
This moves the app template more toward being a more generic starting point for any Flutter application, eliminating some hard-code assumptions about there being a single window/engine pair that is directly bound to the life of the application: - Moves the runloop into its own class, making it capable of servicing any number of engine instances. - Moves the logic for setting up a window containing only a Flutter view into a window subclass for ease of re-use. - Makes quit-on-window-close an optional property. (Long term this should be even more generic, like a quit-when-last-window-closes option, but this is a short-term improvement that removes the binding between the runloop and the window). - Allows for multiple instances of Win32Window to exist without issues relating to the window class registration. Since there are getting to be a non-trivial number of files associated with the runner, this moves the source into a runner/ directory, as is already done on some other platforms. Note that creating multiple Flutter windows at the same time still doesn't work correctly even with this change, but this addresses some of the known issues, and makes it easier to test in the future (e.g., for debugging engine-level issues with multiple instances). Fixes #45397
-