Most iOS embedder developers rely on two simulator builds:
* ios_debug_sim_unopt (for simulators on x64 hosts)
* ios_debug_sim_unopt_arm64 (for simulators on arm64 hosts)
We specify these two builds, for example, in our iOS unit test Xcode project `testing/ios/IosUnitTests/Tests/FlutterEngineConfig.xcconfig`.
Currently `local_engine.json` specifies two simulator builds:
* ios_debug_sim_unopt (for simulators on x64 hosts)
* ios_debug_sim_arm64 (for simulators on arm64 hosts)
While the x64 build specifies the `--unoptimized` flag, the arm64 build does not, which is problematic for those wanting to use both `et` and run the iOS unit tests.
This adds the `--unoptimized` flag for consistency with prevailing practice among iOS embedder developers.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#55092
Initiated by: jonahwilliams
Reason for reverting: framework golden failures.
Original PR Author: jonahwilliams
Reviewed By: {chinmaygarde, jtmcdole}
This change reverts the following previous change:
Follow up to https://github.com/flutter/engine/pull/55060
Currently we have multiple stages of hashing while font rendering, which is relatively expensive for the actualy required workload. First, we hash the contents of all text frames to compute the unique set of glyphs per frame. Then we diff this hash set against the hashmap of glyphs within the atlas. Finally we hash and lookup the final rendered bounds for each glyph.
We can simplify this to 2. hash lookups for glyphs not yet in the atlas and 1. hash lookup for glyphs that are in the atlas. This is done by combing the step where we uniquely compute glyphs per frame with the diff against the current atlas. When this lookup is performed, we also store the glyph position (if found) in the text_frame itself - which allows text contents to skip the last hash, as long as the glyph has already been rendered.
### Before
### After
Using this handy dandy test app:
```dart
import 'package:flutter/material.dart';
void main() {
runApp(MyApp());
}
class MyApp extends StatelessWidget {
Widget build(context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(
title: Text('Platform View'),
),
body: SafeArea(child: Stack(children: [
SizedBox(
width: 380,
height: 380,
child: LinearProgressIndicator(),
),
Stack(
children: List<Widget>.generate(1000, (index) {
// The problem already happens with a small amount of widgets.
// Using an excessive amount of widgets is just to make the problem more evident.
return Text("Lots of Texts represent a Widget with complex components.");
}),
),
Align(
alignment: Alignment.bottomCenter,
child:
TextButton(
child: Text("Button"),
onPressed: () {
print("Tap ${DateTime.now()}");
},
),
),
],
),
),
),
);
}
}
```
Follow up to https://github.com/flutter/engine/pull/55060
Currently we have multiple stages of hashing while font rendering, which is relatively expensive for the actualy required workload. First, we hash the contents of all text frames to compute the unique set of glyphs per frame. Then we diff this hash set against the hashmap of glyphs within the atlas. Finally we hash and lookup the final rendered bounds for each glyph.
We can simplify this to 2. hash lookups for glyphs not yet in the atlas and 1. hash lookup for glyphs that are in the atlas. This is done by combing the step where we uniquely compute glyphs per frame with the diff against the current atlas. When this lookup is performed, we also store the glyph position (if found) in the text_frame itself - which allows text contents to skip the last hash, as long as the glyph has already been rendered.
### Before
### After
Using this handy dandy test app:
```dart
import 'package:flutter/material.dart';
void main() {
runApp(MyApp());
}
class MyApp extends StatelessWidget {
Widget build(context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(
title: Text('Platform View'),
),
body: SafeArea(child: Stack(children: [
SizedBox(
width: 380,
height: 380,
child: LinearProgressIndicator(),
),
Stack(
children: List<Widget>.generate(1000, (index) {
// The problem already happens with a small amount of widgets.
// Using an excessive amount of widgets is just to make the problem more evident.
return Text("Lots of Texts represent a Widget with complex components.");
}),
),
Align(
alignment: Alignment.bottomCenter,
child:
TextButton(
child: Text("Button"),
onPressed: () {
print("Tap ${DateTime.now()}");
},
),
),
],
),
),
),
);
}
}
```
When making a drawAtlas call with no colors, use the faster shader that does not apply blending.
Now that we're switched to experimental canvas, we can remove the copying of the display list data. The draw can directly refer to pointers from the display list structure, as the draw is processed during DL dispatching.
This enhances the overlay optimization by delaying combining pictures to get tighter bounds for the pictures that make up the scene, enabling more sophisticated optimization since we can determine if they intersect with platform views on a per-picture basis.
Fixes https://github.com/flutter/flutter/issues/149863
On a Macbook in Chrome in an example app with an infinite scrolling grid of platform views, this brings the ratio of dropped frames from 93% to 55% (roughly 4 fps to 30 fps).
This is a reland of https://github.com/flutter/engine/pull/54878 with a fix for scenes with pictures and shader masks that are eventually entirely clipped out.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts: flutter/engine#55450
Initiated by: matanlurey
Reason for reverting: Fixed forward in https://github.com/flutter/packages/pull/7712.
Original PR Author: auto-submit[bot]
Reviewed By: {fluttergithubbot}
This change reverts the following previous change:
Reverts: flutter/engine#55418
Initiated by: bdero
Reason for reverting: [Engine->Framework roll breakage](https://github.com/flutter/flutter/issues/155727#issuecomment-2375489803)
Original PR Author: matanlurey
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
Closes https://github.com/flutter/flutter/issues/155131.
Not only did I rename the method, but I also changed the contract slightly - now `onSurfaceAvailable` is _only_ invoked _after_ `onSurfaceDestroyed` has been called. The cost is a single `boolean`, and it honestly makes the API make a lot more sense than someone having to track this themselves.
/cc @johnmccutchan (OOO), and @flutter/android-reviewers.
Reverts: flutter/engine#55402
Initiated by: chingjun
Reason for reverting: caused internal tests to fail.
See b/369740500 for more details.
Original PR Author: harryterkelsen
Reviewed By: {yjbanov}
This change reverts the following previous change:
This enhances the overlay optimization by delaying combining pictures to get tighter bounds for the pictures that make up the scene, enabling more sophisticated optimization since we can determine if they intersect with platform views on a per-picture basis.
Fixes https://github.com/flutter/flutter/issues/149863
On a Macbook in Chrome in an example app with an infinite scrolling grid of platform views, this brings the ratio of dropped frames from 93% to 55% (roughly 4 fps to 30 fps).
This is a reland of https://github.com/flutter/engine/pull/54878 with a fix for scenes with pictures that are eventually entirely clipped out.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/125640
This doesn't actually do anything, instead it forces opaque to false. If developers want opaque to be false, they can just set it directly.
Reverts: flutter/engine#55418
Initiated by: bdero
Reason for reverting: [Engine->Framework roll breakage](https://github.com/flutter/flutter/issues/155727#issuecomment-2375489803)
Original PR Author: matanlurey
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
Closes https://github.com/flutter/flutter/issues/155131.
Not only did I rename the method, but I also changed the contract slightly - now `onSurfaceAvailable` is _only_ invoked _after_ `onSurfaceDestroyed` has been called. The cost is a single `boolean`, and it honestly makes the API make a lot more sense than someone having to track this themselves.
/cc @johnmccutchan (OOO), and @flutter/android-reviewers.
This enhances the overlay optimization by delaying combining pictures to get tighter bounds for the pictures that make up the scene, enabling more sophisticated optimization since we can determine if they intersect with platform views on a per-picture basis.
Fixes https://github.com/flutter/flutter/issues/149863
On a Macbook in Chrome in an example app with an infinite scrolling grid of platform views, this brings the ratio of dropped frames from 93% to 55% (roughly 4 fps to 30 fps).
This is a reland of https://github.com/flutter/engine/pull/54878 with a fix for scenes with pictures that are eventually entirely clipped out.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
When running with merged platform and ui threads, set the dart thread name of the main thread to io.futter.ui. Also change the thread mask settings to avoid creating an unused UI thread.
Goldens are working! and incorrect! use the other texture contents to hopefully fix them. Ratther the the transform, we actually expect to use the src and dst rect to position/transform the texture. Tiled Texture contents does not support a src rect, so switch it to the regular texture contents.
Since we can't see the screenshot we can't really evaluate if this is failing for good/bad reasons. This also uses
the whoe convertToImageREader / readback debugging API that I want to delete.
Closes https://github.com/flutter/flutter/issues/155131.
Not only did I rename the method, but I also changed the contract slightly - now `onSurfaceAvailable` is _only_ invoked _after_ `onSurfaceDestroyed` has been called. The cost is a single `boolean`, and it honestly makes the API make a lot more sense than someone having to track this themselves.
/cc @johnmccutchan (OOO), and @flutter/android-reviewers.
