This repository was archived by the owner on Feb 22, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 9.7k
[e2e] Wait for window.physicalSize so that it works in release mode
#2875
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jiahaog
added a commit
to jiahaog/flutter-plugins
that referenced
this pull request
Jul 15, 2020
…lutter#2875 In release mode, it is possible for the app to start too quickly, which causes `window.physicalSize` to return `Size.zero` and trip the following assertion in the engine: ``` transform_layer.cc(20)] Check failed: transform_.isFinite(). ``` Returning `Size.zero` is a documented behavior [here](https://api.flutter.dev/flutter/dart-ui/Window/physicalSize.html) This occurs when `createViewConfiguration` is overiden (flutter#2805 related), otherwise it falls back to the default window size of 800x600. As such, this PR makes `ensureInitialized` wait for a non-zero `window.physicalSize` before proceeding. I'm not sure if this is the best solution, because: 1. Breaking change to `ensureInitialized`. I'm also not sure if it's a convention for `ensureInitialized` to be async. The key thing we need to do is to set the view configuration correctly before handing control back to the user code, but this does not seem possible with the current sync APIs. 2. Accessing dart:ui.window which is recommended to [avoid](https://api.flutter.dev/flutter/dart-ui/window.html), though this does fall into the exception where: > The only place that `WidgetsBinding.instance.window` is inappropriate is if a `Window` is required before invoking `runApp()`. In that case, it is acceptable (though unfortunate) to use this object statically. Some other alternatives I can think of: - Introduce another method to wait for the physical size, but this seems more clunky to users. - Recommend users call `setSurfaceSize` instead and explicitly pass in the desired size - Don't use `window.physicalSize` and instead always use the defaults of 800x600
a0ce651 to
1723d19
Compare
jiahaog
added a commit
to jiahaog/flutter-plugins
that referenced
this pull request
Jul 15, 2020
…lutter#2875 In release mode, it is possible for the app to start too quickly, which causes `window.physicalSize` to return `Size.zero` and trip the following assertion in the engine: ``` transform_layer.cc(20)] Check failed: transform_.isFinite(). ``` Returning `Size.zero` is a documented behavior [here](https://api.flutter.dev/flutter/dart-ui/Window/physicalSize.html) This occurs when `createViewConfiguration` is overiden (flutter#2805 related), otherwise it falls back to the default window size of 800x600. As such, this PR makes `ensureInitialized` wait for a non-zero `window.physicalSize` before proceeding. I'm not sure if this is the best solution, because: 1. Breaking change to `ensureInitialized`. I'm also not sure if it's a convention for `ensureInitialized` to be async. The key thing we need to do is to set the view configuration correctly before handing control back to the user code, but this does not seem possible with the current sync APIs. 2. Accessing dart:ui.window which is recommended to [avoid](https://api.flutter.dev/flutter/dart-ui/window.html), though this does fall into the exception where: > The only place that `WidgetsBinding.instance.window` is inappropriate is if a `Window` is required before invoking `runApp()`. In that case, it is acceptable (though unfortunate) to use this object statically. Some other alternatives I can think of: - Introduce another method to wait for the physical size, but this seems more clunky to users. - Recommend users call `setSurfaceSize` instead and explicitly pass in the desired size - Don't use `window.physicalSize` and instead always use the defaults of 800x600
1723d19 to
e4df438
Compare
Member
Author
|
@dnfield not sure if there are better ways to do this, let me know what you think! |
…lutter#2875 In release mode, it is possible for the app to start too quickly, which causes `window.physicalSize` to return `Size.zero` and trip the following assertion in the engine: ``` transform_layer.cc(20)] Check failed: transform_.isFinite(). ``` Returning `Size.zero` is a documented behavior [here](https://api.flutter.dev/flutter/dart-ui/Window/physicalSize.html) This occurs when `createViewConfiguration` is overiden (flutter#2805 related), otherwise it falls back to the default window size of 800x600. As such, this PR makes `ensureInitialized` wait for a non-zero `window.physicalSize` before proceeding. I'm not sure if this is the best solution, because: 1. Breaking change to `ensureInitialized`. I'm also not sure if it's a convention for `ensureInitialized` to be async. The key thing we need to do is to set the view configuration correctly before handing control back to the user code, but this does not seem possible with the current sync APIs. 2. Accessing dart:ui.window which is recommended to [avoid](https://api.flutter.dev/flutter/dart-ui/window.html), though this does fall into the exception where: > The only place that `WidgetsBinding.instance.window` is inappropriate is if a `Window` is required before invoking `runApp()`. In that case, it is acceptable (though unfortunate) to use this object statically. Some other alternatives I can think of: - Introduce another method to wait for the physical size, but this seems more clunky to users. - Recommend users call `setSurfaceSize` instead and explicitly pass in the desired size - Don't use `window.physicalSize` and instead always use the defaults of 800x600
e4df438 to
e6ad2dc
Compare
Member
Author
|
Upon further investigation this only happens when I try to build the engine from source, closing for now |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
In release mode, it is possible for the app to start too quickly, which causes
window.physicalSizeto returnSize.zeroand trip the following assertion in the engine:Returning
Size.zerois a documented behavior hereThis occurs when
createViewConfigurationis overiden (#2805 related), otherwise it falls back to the default window size of 800x600. As such, this PR makesensureInitializedwait for a non-zerowindow.physicalSizebefore proceeding.I'm not sure if this is the best solution, because:
ensureInitialized. I'm also not sure if it's a convention forensureInitializedto be async. The key thing we need to do is to set the view configuration correctly before handing control back to the user code, but this does not seem possible with the current sync APIs.Some other alternatives I can think of:
setSurfaceSizeinstead and explicitly pass in the desired sizewindow.physicalSizeand instead always use the defaults of 800x600Related Issues
#2805
Maybe #36533
b/161208057
Breaking Change
Does your PR require plugin users to manually update their apps to accommodate your change?