Fixes https://github.com/flutter/flutter/issues/163315
Fixes https://github.com/flutter/flutter/issues/163521
Fixes https://github.com/flutter/flutter/issues/142641
OpenGL has an inverted coordinate system (bottom left is zero) compared
to Metal/Vulkan (top left is zero). We handle this by rendering things
upside down on OpenGL. Unfortunately this can leak out of the renderer
via readback (toImage), so we need to make sure to undo the inversion.
This is not performed for the "TextureCoordinateSystem::kUploadFromHost"
state as that indicates the texture is already "right side up".
Powered by the new and amazing `unnecessary_ignore` lint.
We're not enabling this lint by default because being able to
temporarily use ignores that don't ignore anything is a powerful tool to
enable migrations. We should turn this lint on locally periodically,
though, and clean up all outdated ignores.
Resolves https://github.com/flutter/flutter/issues/143891.
This patch includes breaking changes, but this API is still in preview.
* Breaking: Rename `Texture.GetBaseMipLevelSizeInBytes` to
`Texture.getBaseMipLevelSizeInBytes`.
* Breaking: Make `Texture.overwrite` throw exception instead of
returning false.
* Non-breaking: Make `DeviceBuffer`/`Texture` creation throw exceptions
instead of returning nullables.
We can incrementally add more specific exceptions for resource creation
failure.
Fixes https://github.com/flutter/flutter/issues/162128
Zero dimensioned rectangle blurs were causing the setup code to generate
NaN values. This condition could also happen for some very thin or short
rectangles so rather than just rule out zero-dimensioned rectangles, the
uniforms are checked for NaN values and the operation is skipped in
those cases.
🚫 **BLOCKED** : Do not merge until
https://github.com/flutter/flutter/issues/161261 (additional test
coverage).
---
This PR eliminates (1) `scenario_app/android`, and all references to an
Android `scenario_app`, including documentation, CI configuration, build
rules, test runner, Android-side test application, and (2), to verify
and disambiguate the remains, renames the folder `ios_scenario_app`,
which is now accurate.
It also eliminates elements that were _only_ used in the Android-side
scenario_app, such as Firebase Test Lab uploading.
I would be open to doing this in phases if we thought it was better to
do so, but given its mostly a mechanical change (and by renaming the
directory, references can be checked merely by looking for
`/\bscenario_app/`, I believe this is safe to iterate on and eventually
merge after the holidays.
## Background
As of the merged mono-repo, there is no longer a requirement for the
engine to be testable as a standalone unit.
As an example,
[`%ENGINE%/testing/scenario_app`](3762f2e973/engine/src/flutter/testing/scenario_app),
which was intended to _emulate_ the Flutter framework (and some of
`flutter_tools` tooling), load the iOS and Android embedder, and run
various "scenarios" (which ran a combination of `dart:ui` code and
Android Java/iOS Obj-C) verifying golden-file screenshots.
Instead, it is now possible to write and run _real_ (full) Flutter apps
the same way that an end-user (or our own tests) would. One such example
is
[`dev/native_driver_test`](https://github.com/flutter/flutter/tree/master/dev/integration_tests/native_driver_test),
which is a full-fledged Flutter app, which uses standard tooling (i.e.
`flutter`), to test most of the same elements that previously were only
tested in the Android version of `scenario_app`.
These cause ambiguous compiler reference errors on some GCC versions.
And, the errors seem right. But, newer versions of clang seem to resolve
that ambiguity by also checking if the references to the types are also
references to identical types.
Per the chat with Jim, also added the Dl prefix to those types.
No change in functionality. Just a rename of the types and removal of
the now unnecessary typedefs.
Fixes https://github.com/flutter/flutter/issues/161262
Sometimes we end up with clip replay entities that have clip depth
values substantially below the current depth. I suspect this is due to
either mismatched save/restore or a bug in our code. Update: this isn't
a bug/bug but its definitely a bug. We can have multiple clips per save,
but the restore will remove at most one from the record/replay.
If a clip has a depth value that is less than the current clip depth, it
cannot by definition impact anything that draws after it.
Fixes https://github.com/flutter/flutter/issues/161374
When we round out the texture size for a saveLayer, also round out the
coverage so that the drawing origin is correct. Otherwise we may
actually cut off the top left edge of rendering.
---------
Co-authored-by: gaaclarke <30870216+gaaclarke@users.noreply.github.com>
When processing the metadata for a struct with an array, incorporate the
padding into the layout. Previously we would register a vec3[n] array as
being 4*n bytes (including the padding), but when uploading this would
result in us writing data into the padding and then leave the rest
uninitialized. now we correctly insert a padding element between 3 byte
elements.
Fixes https://github.com/flutter/flutter/issues/161645
Fixes SkRSXform task in https://github.com/flutter/flutter/issues/161456
Removes (nearly) all uses of Skia SkRSXform object from DisplayList and
replaces it with a new Impeller RSTransform geometry object.
There are remaining uses in:
- Skia adapter code which needs to convert them back to SkRSXform when
using the Skia backend
- dl_rendering_tests which is waiting for a major conversion effort
- ?Fuchsia? code has an SkCanvas spy adapter used in its embedder code
(not DisplayList related)
- web_ui/skwasm
Towards https://github.com/flutter/flutter/issues/161406.
The goal is to, assuming this is WAI, move the `bringup: true` build
(the newly created one) to presubmit, and then in a follow-up PR, remove
the `tests: [...]` (and test dependencies) from
`linux_host_engine.json`, meaning that it would be a build/archive only
builder, and this _new_ builder would be a build/test one.
We talked about it being hypothetically better to _not_ build the engine
multiple times, and decided for now to depend on RBE and not try to
create stages or download artifacts created from another builder, but if
@zanderso has another suggestion here is the place to chime in :)
(Btw if we like this approach, I'll create a task list of every builder
that needs to be migrated)
Auto-generated by `dart testing/skia_gold_client/tool/generate.dart`.
This is just to make sure that everything is working after the recent
configuration.
Closes https://github.com/flutter/flutter/issues/157206.
I also added a `prefix` that will default to `engine.` to avoid
accidentally stomping on golden names across repos.
/cc @gaaclarke for visibility, @Piinks for visibility.
(I would love to get rid of this "engine copy" of the client as part of
longer-term mono repo deduplication).
Unblocks https://github.com/flutter/flutter/pull/160556.
Currently the merge queue runs in post-submit mode, which looks for (and
fails to find) digests for PRs that have not yet been submitted,
blocking the engine goldens from being enabled/checked in
https://github.com/flutter/flutter/pull/160556. This PR is a proposal to
fix that by skipping the tests.
We might decide instead that tests should not be running in the merge
queue at all, in which case we will _not_ merge this PR and will change
how the merge queue works instead. Otherwise this PR is a proof of
concept of [aligning implementations with the
framework](a9b3f6c042/packages/flutter_goldens/lib/flutter_goldens.dart (L338)).
When running `dart format` over these lines the `// ignore` ended up on a line where it wasn't properly ignoring the lint. This adjusts the placement of `// ignore`s so they will continue to ignore the right thing even after the code is auto formatted.
I am hoping that if we do this now the large PR that formats the entire repo will go in smoother without manual intervention.
This change adds entry-point annotations to methods and classes accessed
by native code during engine tests. Currently, entry point annotations
are not checked by the Dart VM when running in JIT mode, only in AOT
mode. In order to also enforce entry point annotations in JIT mode,
first tests in Flutter must be appropriately annotated to avoid roll
failures.
Related issues:
* https://github.com/flutter/flutter/issues/118608
* https://github.com/dart-lang/sdk/issues/50649
As per the [spec](https://www.w3.org/TR/png/#fcTL-chunk):
> The frame must be rendered within the region defined by x_offset, y_offset, width, and height. This region may not fall outside of the default image; thus x_offset plus width must not be greater than the [IHDR](https://www.w3.org/TR/png/#11IHDR) width; similarly y_offset plus height must not be greater than the [IHDR](https://www.w3.org/TR/png/#11IHDR) height.
While recently updating the DlColorSource sources I noticed some questionably implementation choices in the Color variant of the color sources.
I then realized that there was no public use of these classes (other than mostly their own unit tests) and so they should be deleted to focus on implementing the variants that are actually used by Flutter.
A new source code/header structure was introduced when the DlColorSource and DlImageFilter objects were migrated to Impeller geometry classes. Even though the DlColorFilter objects did not depend on Skia geometry objects, they need to be updated to the new source layout for consistency.
Reverts: flutter/engine#56606
Initiated by: LongCatIsLooong
Reason for reverting: https://github.com/flutter/flutter/issues/159456
Original PR Author: LongCatIsLooong
Reviewed By: {chunhtai, cbracken}
This change reverts the following previous change:
This PR adds basic FKA scrolling support: when the iOS focus (the focus state is maintained separately from the framework focus, see the previous PR) switches to an item in a scrollable container that is too close to the edge of the viewport, the container will scroll to make sure the next item is visible.
Previous PR for context: https://github.com/flutter/engine/pull/55964https://github.com/user-attachments/assets/84ae5153-f955-4d23-9901-ce942c0e98ac
### Why the UIScrollView subclass in the focus hierarchy
The iOS focus system does not provide an API that allows apps to notify it of focus highlight changes. So if we were to keep using the transforms sent by the framework as-is and not introducing any UIViews in the focus hierarchy, the focus highlight will be positioned at the wrong location after scrolling (via FKA or via framework). That does not seem to be part of the public API and the focus system seems to only know how to properly highlight focusable UIViews.
### Things that currently may not work
1. Nested scroll views (have not tried to verify)
The `UIScrollView`s are always subviews of the `FlutterView`. If there are nested scrollables the focus system may not be able to properly determine the focus hierarchy (in theory the iOS focus system should never depend on `UIView.parentView` but I haven't tried to verify that).
2. If the next item is too far below the bottom of the screen and there is a tab bar with focusable items, the focus will be transferred to tab bar instead of the next item in the list
Video demo (as you can see the scrolling is really finicky):
https://github.com/user-attachments/assets/51c2bfe4-d7b3-4614-aa49-4256214f8978
I've tried doing the same thing using a `UITableView` with similar configurations but it seems to have the same problem. I'll try to dig a bit deeper into this and see if there's a workaround.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds basic FKA scrolling support: when the iOS focus (the focus state is maintained separately from the framework focus, see the previous PR) switches to an item in a scrollable container that is too close to the edge of the viewport, the container will scroll to make sure the next item is visible.
Previous PR for context: https://github.com/flutter/engine/pull/55964https://github.com/user-attachments/assets/84ae5153-f955-4d23-9901-ce942c0e98ac
### Why the UIScrollView subclass in the focus hierarchy
The iOS focus system does not provide an API that allows apps to notify it of focus highlight changes. So if we were to keep using the transforms sent by the framework as-is and not introducing any UIViews in the focus hierarchy, the focus highlight will be positioned at the wrong location after scrolling (via FKA or via framework). That does not seem to be part of the public API and the focus system seems to only know how to properly highlight focusable UIViews.
### Things that currently may not work
1. Nested scroll views (have not tried to verify)
The `UIScrollView`s are always subviews of the `FlutterView`. If there are nested scrollables the focus system may not be able to properly determine the focus hierarchy (in theory the iOS focus system should never depend on `UIView.parentView` but I haven't tried to verify that).
2. If the next item is too far below the bottom of the screen and there is a tab bar with focusable items, the focus will be transferred to tab bar instead of the next item in the list
Video demo (as you can see the scrolling is really finicky):
https://github.com/user-attachments/assets/51c2bfe4-d7b3-4614-aa49-4256214f8978
I've tried doing the same thing using a `UITableView` with similar configurations but it seems to have the same problem. I'll try to dig a bit deeper into this and see if there's a workaround.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The DlColorSource code uses Skia geometry classes for its internal computations. This PR switches those implementations to use the Impeller geometry classes for consistency and 3rd party header file independence.
The Info.plist override was missed earlier.
The main changes to the tests are due to the UI thread merge with the platform thread. The amendment to the "spawn" API are due to the fact that the assertions checked for the presence of GrDirectContext which will never exist with Impeller.
Unblocks https://github.com/flutter/engine/pull/56706
This PR introduces a `NativeAssetsManifest.json` next to the `AssetManifest.json` and `FontManifest.json`. This removes the need for embedding the native assets mapping inside the kernel file and will enable decoupling native assets building and bundling from the kernel compilation in flutter tools. This will then allow us to remove dry-run from the build hook protocol.
(It also means all isolate groups will have the same native assets. However, since Flutter does not support `Isolate.spawnUri` from kernel files anyways, this is not a regression.)
This manifest is parsed eagerly on startup by the engine in a manner similar to how the font manifest is parsed. The manifest contents need to be available in the callback for resolving assets, which does not have access to the engine. Therefore the parsed manifest is `NativeAssetsManager` stored in the `IsolateGroupData`. The engine passes it in on isolate group creation, and the FFI callbacks access it from the isolate group data.
Issue:
* https://github.com/flutter/flutter/issues/154425
Related PRs:
* https://dart-review.googlesource.com/c/sdk/+/388161
Follow up work:
* This PR does not yet remove the engine callbacks registered via the dart_api that rely on kernel embedding. If we were to do that in this PR, it would require a manual roll of the engine into flutter/flutter with the PR that switches flutter_tools to emit the native assets manifest instead of embedding in kernel, and a manual roll into g3 to switch emitting a manifest instead of embedding in kernel. A TODO is left in the code for those callbacks to be removed.
## Testing
Most of this PR cannot be tested in isolation. The code in this PR is heavily exercised in the follow up flutter_tools PR which creates the `NativeAssetsManifest.json` and removes the embedding of native assets in kernel files.
* This PR adds a unit test for parsing the JSON manifest.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The DlImageFilter code uses Skia geometry classes for its internal computations. This PR switches those implementations to use the Impeller geometry classes for consistency and 3rd party header file independence.
Also updates the image_filter_test.dart expected color values for a blur unit test. The legacy blur algorithm would a) treat very small blur sigmas as the identity even though the effect was still perceptible and b) was very inaccurate for sigmas < 2. The unit test used a sigma of 1.0 so fell within the inaccurate range but the expected values appear to have been taken directly from the original Skia output. This updates them to match the output of the new algorithm (which is also more consistent between CPU and GPU).
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
For consistency with the Test.*Context classes for other backends, which live in their own implementation file with their own header, extract TestEGLContext to its own header and TU so that in cases where only a TestEGLContext is required (e.g. EmbedderTestBackingStoreProducerGL), we don't need to include all the various test GL surface classes as well.
GetEGLError is used by both TestEGLContext and the TestGLSurface classes, so moves to its own utils file.
No tests because this is a refactoring with no semantic changes, and the code itself is test code.
Issue: https://github.com/flutter/flutter/issues/158998
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Enables the `-fobjc-arc` compiler flag for Objective-C and Objective-C++
translation units.
Eliminates the flutter_cflags_objc[c]_arc settings, since they're now
redundant.
All Obj-C/Obj-C++ code in our codebase has now been migrated to ARC.
Issue: https://github.com/flutter/flutter/issues/137801
