… mode

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 overriden (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.

Another alternative we can do would be to introduce another method to wait for the physical size, but this seems more clunky to users.

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 overriden (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.

Another alternative we can do would be to introduce another method to wait for the physical size, but this seems more clunky to users.

…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

…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

…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