This PR enforces the rules as documented in `FlutterView.Render`, where
calls in illegal situations should be ignored - but have never been
enforced.
```
/// This function must be called within the scope of the
/// [PlatformDispatcher.onBeginFrame] or [PlatformDispatcher.onDrawFrame]
/// callbacks being invoked.
///
/// If this function is called a second time during a single
/// [PlatformDispatcher.onBeginFrame]/[PlatformDispatcher.onDrawFrame]
/// callback sequence or called outside the scope of those callbacks, the call
/// will be ignored.
```
This rule is very important to implementing multi-view without having to
introduce new APIs. However, currently these illegal calls are not
ignored, and historically many tests (especially integration tests) were
unknowingly running based on this fact. @goderbauer did great work by
eliminating these cases in g3, and it's time for us to make sure these
calls are ignored.
Most effort of this PR goes to unit testing the changes. Some part of
`Shell::Create` is extracted into a static function to avoid duplicate
code.
## Pre-launch Checklist
- [ ] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [ ] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [ ] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [ ] I listed at least one issue that this PR fixes in the description
above.
- [ ] I added new tests to check the change I am making or feature I am
adding, or Hixie said the PR is test-exempt. See [testing the engine]
for instructions on writing and running engine tests.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [ ] All existing and new tests are passing.
If you need help, consider asking for advice on the #hackers-new channel
on [Discord].
<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#overview
[Tree Hygiene]: https://github.com/flutter/flutter/wiki/Tree-hygiene
[Flutter Style Guide]:
https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo
[C++, Objective-C, Java style guides]:
https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
[testing the engine]:
https://github.com/flutter/flutter/wiki/Testing-the-engine
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/wiki/Tree-hygiene#handling-breaking-changes
[Discord]: https://github.com/flutter/flutter/wiki/Chat
Update: Blocked on https://github.com/flutter/engine/pull/44912 landing,
and merging into google3.
---
Partial work towards https://github.com/flutter/flutter/issues/112498.
_**tl;dr**: In Impeller's backend we intend to _always_ dither
gradients, and never allow any changes long-term (i.e., write your own
shader if you want different behavior) with the assumption that dithered
gradients look better most of the time, and don't typically hurt
elsewhere._
Note that, at the time of this writing, I couldn't find a single case of
this being set explicitly to `true` inside Google, and there are between
[100 and 200 publicly accessible on
GitHub](https://github.com/search?q=%22Paint.enableDithering%22+language%3ADart&type=code&l=Dart),
of which virtually all are setting it explicitly to `true`.
There are some (valid) concerns this would cause a lot of golden-file
image diffs, so I'm going to seek explicit approval from the Google
testing team as well as someone from the framework team before landing
this commit.
The PR improves the code size and runtime performance of fallback font selection.
### Performance improvements
Initialization of the data structures to support fallback font selection has been moved from creating the FallbackFontManager (first frame) to the first use, i.e. the first frame actually needing a fallback font.
The numbers reported below are for a lightly edited version of the counter demo that appends to the counter about ~300 missing code points that need ~25 fallback fonts to cover the missing code points. Timings taken from a few profiles on my performance workstation.
| | Before | After |
| --- | ---: | ---: |
| FallbackFontManager() |~100ms | <2ms |
| First need | 0ms | 12ms |
| Subsequent need | 20-30ms | <1ms |
### Size improvements
| | Before | After | Î |
| --- | ---: | ---: | ---: |
| main.dart.js | 1586405 | 1477319 | -109086 (-6.87%) |
| brotli -9 | 427304 | 401611 | -25693 (-6.01%) |
### Algorithm notes
#### Startup
The old algorithm built an interval tree from the code point ranges of the ~140 fallback fonts and uses the interval tree to build a list of fonts that support each missing code point. The new algorithm uses a binary search map that directly produces the list of fonts. There are fewer binary search ranges (~22k) than the aggregate ranges for all the fonts (~26k).
Most of the startup time gain comes from using a data unpacks directly into a useful form rather than needing processing to build an interval tree (~12ms vs ~100ms).
#### Running
The runtime for font selection is greatly improved for several reasons
- The code point space is partitioned into components so that code point counting can be batched.
- When a font is selected, the counts are updated incrementally rather than being recomputed.
- The counts are held in fields of the NotoFont and component objects rather than in Maps or Sets.
Batching, incremental update and avoiding hash tables are roughly multiplicative in effect.
## Issues
- https://github.com/flutter/flutter/issues/131440
*If you had to change anything in the [flutter/tests] repo, include a link to the migration guide as per the [breaking change policy].*
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Relands https://github.com/flutter/engine/pull/45131
Fixes https://github.com/flutter/flutter/issues/132416
Differences from last time:
- Some minor merge conflict fixes
- Use the RTree to get the bounds instead of recalculating the bounds
- Make the iOS platform view controller implementation use the impeller-aware slices instead of the display list ones. This has been fixed for Android and the desktop embedding, but I missed iOS. The unit tests weren't actually running before I branched for my PR, @zanderso fixed them up separately and this resulted in catching the failures on post submit last time.
This API will help with situations in which the user has a browser
resource that they want to transform into a `ui.Image` and render
directly into the layer tree. Most browser resources can be converted to
an `ImageBitmap` via the `createImageBitmap` API.
This PR moves the source of truth for`devicePixelRatio` to the `EngineFlutterDisplay` singleton.
Main things that this PR is trying to do:
- `EngineFlutterDisplay` is a singleton that represents information about the display.
- The `devicePixelRatio` can be overriden in tests.
- The `browserDevicePixelRatio` gets the value directly from the browser and can't be overriden.
- Remove `EngineSingletonFlutterWindow` and incorporate it into `EngineFlutterWindow`.
This allows us to remove libpng from skia entirely, which saves us about 25kb brotli compressed.
Note, this should not change any functionality. The existing functionality is covered by the unit tests here: bfcb9d08e8/lib/web_ui/test/ui/image_golden_test.dart (L197-L197)
This implements platform views in Skwasm. There are a number of substantial changes rolled up in this change, including:
* Reworked the rendering system to use multiple canvases with a single WebGL context, via ImageBitmap rendering.
* Reworked our object management and bindings to use the `__externref_t` construct in C code.
* Upgraded emscripten to a much newer version
* Generified skwasm's scene builder to be able to work with any renderer that can produce `ImageBitmap` objects from Pictures, and whose `Canvas`, `Picture` and `ImageFilter` objects conform to `SceneCanvas`/`ScenePicture`/`SceneImageFilter`
For platform views themselves, most stuff is implemented except for clipping. I plan on doing that in a subsequent change.
Reverts flutter/engine#45131
This is failing the Impeller variants of the unobstructed platform views tests:
https://ci.chromium.org/ui/p/flutter/builders/prod/Mac%20Production%20Engine%20Drone/132249/overview
```
Failing tests:
-[UnobstructedPlatformViewTests testPlatformViewsMaxOverlays]
-[UnobstructedPlatformViewTests testOneOverlay]
-[UnobstructedPlatformViewTests testOneOverlayPartialIntersection]
-[UnobstructedPlatformViewTests testTwoIntersectingOverlays]
-[UnobstructedPlatformViewTests testOneOverlayAndTwoIntersectingOverlays]
** TEST FAILED **
```
We've retried it a few times so I suspect this isn't a flake.
This is a reland of https://github.com/flutter/engine/pull/44248
Fixes https://github.com/flutter/flutter/issues/132416
Changes from last time:
- The `drawPoints` benchmark was failing to render anything meaningful because of an error in `AiksLayer` that resulted in an infinitely sized bounding rectangle poisoning the bounds with `NaN` (this happens, for example, with a `drawPaint` call, which that benchmark happens to use). Added a test covering this and filed https://github.com/flutter/flutter/issues/132770 to explore ways to avoid this in the future.
- There was a bug in `DlAiksCanvas::SaveLayer` where a `nullptr` `paint` but non-`nullptr` `backdrop` was failing to actually save the layer. This resulted in incorrect rendering.
- There was a bug in `impeller::Canvas::DrawPicture` that resulted in incorrect stencil depth counting. That was fixed separately by @bdero, but was the cause of incorrect rendering in some Wonderous screens.
- I've added a simple implementation for `AiksLayer::IsReplacing`. It does not currently compare as deeply as the `DisplayListLayer` version potentially does, but it is good enough to avoid the regression noted in https://github.com/flutter/flutter/issues/132071. That regression was on a benchmark that greatly benefits from partial repaint. With the new implementation, it still gains partial repaint where it previously did not. There is more work that can be done here, filed https://github.com/flutter/flutter/issues/133361 to track that work.
I merged but did not fully integrate the `DisplayListBuilder`/`CanvasToReceiver` work that @flar has done. I have a local experiment with that, but would prefer to see this land and run through the device lab so we get some better comparison numbers for which one performs better.
Resolves https://github.com/flutter/flutter/issues/132516.
Add `impeller::HostBuffer` wrapper to Flutter GPU.
* Allows for lazy batch uploads of sparse host data to the GPU.
* Handles platform alignment requirements.
* API returns buffer view handles that will be fed to commands.
DisplayListBuilder grew over time from a class that implemented a developer-unfriendly stateful API into one that implemented both the developer-friendly DlCanvas API as well as its original stateful API. Over time, the stateful API was buried under a "testing only" facade.
In the meantime, the optimization features that it applies to the DlCanvas calls before it records the operations in a DlOp store are useful without the recording process and so I've been wanting to break those into 2 parts for a while with the goal of removing all stateful APIs from DisplayListBuilder (see https://github.com/flutter/flutter/issues/108303).
This PR takes a major step along that direction by splitting DisplayListBuilder into essentially a convenience class that marries 2 new classes together to achieve its old functionality:
- `DlCanvasToReceiver` - a class that implements DlCanvas, optimizes common situations, and then sends commands to any object that implements `DlOpReceiver`
- `DlOpRecorder` - an implementation of DlOpReceiver that records the operations in a buffer from which to create a `DisplayList` object
- `DisplayListBuilder` now inherits from DlCanvasToReceiver to get the optimizations and provides it with an instance of `DlOpRecorder` as the receiver that it will send its results to
- Similarly, a `DlCanvasToReceiver` instance could be directed to an `impeller:DlDispatcher` to achieve a more straight-through path from the DlCanvas interface to impeller Pictures.
