closesflutter/flutter#53107
This PR introduces support for `AppLifecycleState` on Web, aligning the web's lifecycle events with those of the mobile platforms. This ensures a more consistent developer experience and better lifecycle management across all platforms.
**PR includes:**
- Page Visibility Handling: Integrated the `visibilitychange` DOM event to determine if the app is in a `resumed` or `paused` state based on the visibility state of the document.
- Page Transition Handling: Used `beforeunload` events to better manage the `detached` state.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Now that the HostBuffer isn't implementing Buffer, there is really no reason to have a Buffer/DeviceBuffer split. make BufferViews use a DeviceBuffer, and remove the data ptr from buffer views (as we can always reach into the device buffer).
Makes some other cleanups too, since we always use a std::shared_ptr<DeviceBuffer>, then we can eliminated the shared_from_this call for AsBufferView by making this a static method.
Fixes https://github.com/flutter/flutter/issues/122823
Fixes https://github.com/flutter/flutter/issues/129659
Fixes https://github.com/flutter/flutter/issues/123741
This patch makes runtime stage/fragment program stuff work on Vulkan for Android.
It will need flutter/flutter#140976 for that to become a reality for flutter_tools users.
Compiling with relaxed Vulkan semantics still has an issue: shaders that use `sampler2D` with an explicitly set `location` on the `layout` will fail to compile with an error documented in https://github.com/flutter/flutter/issues/141219.
I think there might still be some issues with fragment programs on Vulkan, but this should at least be a good starting point and unblocks ink_sparkle.frag usage in the framework.
I've deleted some runtime_stage related code that would never get used - for example, enum related code that indicates we might support a bunch of data types that we do not and probably never will support in this API.
This patch will be important for Android/Vulkan, where we'll need to bundle GLES, Vulkan, and SkSL (at least for now).
I've refactored impellerc_main to break up some of the larger methods into more granular ones.
I've also changed the way that the `IPLR` output works so that we create as many compilers as runtime stages requested.
We still are in a weird situation where we create one "Default" compiler for the reflection data and depfile. I don't think that needs to be addressed in this patch, but we should do something about this. I've talked a little with @bdero and @jonahwilliams - it will probably involve something like making the generated reflection data a bit more flexible than it currently is so that it can more ergonomically capture different platform anomalies - we could do this either by having a compiler type that is explicitly for generating reflection data rather than using one arbitrary one and making the reflector try to be platform agnostic. I've filed a couple TODOs related to this and linked them in the patch.
Fixes https://github.com/flutter/flutter/issues/140817
This is part of the work towards supporting OpenGLES and Vulkan for runtime stage shaders.
Removes some redundant work we had around SkSL. Now only bundles the shaders we actually ask for from the command line.
@bdero, we should figure out if this is the right approach for flutter_gpu.
With this change, the IPLR format goes from having a root table of shader related information to a root table of shader information per `sksl`, `metal`, `opengles`, and `vulkan` platforms.
This may end up allowing us to revert https://github.com/flutter/engine/pull/47278, but I'm not sure I understand all the implications of that at this point.
I have run some but not all tests locally.
This reverts commit 87171e73397f7edfd4c145fbaebdd7208954debf.
Internal performance test shows that this PR negatively affects startup time. I'll reland this PR in parts.
b/307872797
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This PR adds `String? identifier` to `SemanticsUpdateBuilder` (currently it's only available in the temproary `SemanticsUpdateBuilderNew` API.
This is mainly targeted at https://github.com/flutter/flutter/issues/17988
Steps:
part 1: [engine] add `SemanticsUpdateBuilderNew` https://github.com/flutter/engine/pull/47961
part 2: [flutter] use `SemanticsUpdateBuilderNew` https://github.com/flutter/flutter/pull/138331
**part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`** <-- we are here
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
Accompanying framework PR: https://github.com/flutter/flutter/pull/138331
This PR implements support for exposing `SemanticsProperties.identifier` on Android as `resource-id`. Mainly targeted at https://github.com/flutter/flutter/issues/17988. Would also fix https://github.com/flutter/flutter/issues/issues/137735 but it was marked as duplicate. Anyway, there's a lot of context in that issue.
This PR requires changing the `SemanticsUpdateBuilder` interface (defined in engine) that framework depends on, so it requires introducing a temporary API ([see question I asked on Discord](https://discord.com/channels/608014603317936148/608018585025118217/1174845658033819729) to learn more about this approach).
Steps:
**part 1: [engine] add `SemanticsUpdateBuilderNew`** <-- we are here
part 2: [flutter] use `SemanticsUpdateBuilderNew`
part 3: [engine] update `SemanticsUpdateBuilder` to be the same as `SemanticsUpdateBuilderNew`*
part 4: [flutter] use (now updated) `SemanticsUpdateBuilder` again.
part 5: [engine] remove `SemanticsBuilderNew`
I'd like to do these changes first, and only then continue with [the proper framework PR](https://github.com/flutter/flutter/pull/138331).
*More specifically: update `SemanticsUpdateBuilder.updateNode()` to be the same as `SemanticsUpdateBuilderNew.updateNode()`. Number of arguments that function takes is the only change.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The root slice of a surface frame was requesting the construction of an RTree from its DisplayList when it was built from a layer tree, but since the layer tree already does branch culling, it would not benefit from any further culling during `DisplayList::Dispatch`. Further, if there are platform views present in the layer tree then they will need an RTree to accurately convey "pixel ownership" information to the platform, but the root slice lives below any and all platform views, so it is the only slice that doesn't need an RTree for that case.
The cost of having an RTree in that slice was the accumulation of information and lists of rects that would never prove useful.
Towards https://github.com/flutter/flutter/issues/134501.
This PR makes the following changes to the public dart:ui API:
* It adds the `FlutterView.pysicalConstraints` property that describes max and min width and height for a view. The framework is allowed to size the `FlutterView` to any `Size` that meets these constraints.
* It adds an optional `size` argument to `FlutterView.render`. The framework provides the chosen `Size` that meets the aforementioned constraints to the `render` method. If the `FlutterView.pysicalConstraints` are tight (minHeight == maxHeight and minWidth == maxWidth) the argument is optional to remain backwards compatible. In all other cases, a `Size` must be provided.
* It adds a `ViewConstraints` class, which is basically the `dart:ui` version of `BoxConstraints` (This is similar to how we have `ViewPadding` in dart:ui to mirror `EdgeInsets` from the framework). It describes the constraints of a `FlutterView`, i.e. it powers the `FlutterView.pysicalConstraints` property.
This change does not wire anything up to the embedders. For now, `FlutterView.pysicalConstraints` just returns tight constraints for the embedder-provided size of the view (`FlutterView.physicalSize`) and the size provided to `FlutterView.render` is ignored (after it is checked that it meets the constrains).
This PR enables the framework to implement the new dynamic view sizing and embedders to separately expose the new functionality to their clients.
Presubmits will fail until https://github.com/flutter/flutter/pull/138565 is submitted to the framework.
**DO NOT SUBMIT until https://github.com/flutter/flutter/pull/138648 is ready.**
Reverts flutter/engine#48000
Initiated by: jonahwilliams
This change reverts the following previous change:
Original Description:
I just ... deleted `text_box.h` as it appears unused and unreferenced?
---
Work towards https://github.com/flutter/flutter/issues/134969.
All changes were made automatically (i.e. with `--fix`).
I just ... deleted `text_box.h` as it appears unused and unreferenced?
---
Work towards https://github.com/flutter/flutter/issues/134969.
All changes were made automatically (i.e. with `--fix`).
Reverts flutter/engine#47825
Initiated by: zanderso
This change reverts the following previous change:
Original Description:
Looks like this was proactively added in https://github.com/flutter/engine/pull/20496, but never wired up to anything on any platform. It is also unused in framework and customer code; we never exposed this on e.g. MediaQuery.
Related framework PR: https://github.com/flutter/flutter/pull/138103 (Checks will fail until that PR is submitted).
The new `BUILD.gn` files in the Engine tree can't go under
`build/secondary` because Skia still has its own, and they'd be selected
first. So, this PR puts the new `BUILD.gn` files under `flutter/skia`.
## Description
Before we deprecate the `RawKeyEvent` code, it needs to provide parity in functionality. One thing that is missing is the `eventSource` field from the `RawKeyEventDataAndroid` class, which provides the device type for the event.
See https://developer.android.com/reference/android/view/InputDevice#SOURCE_KEYBOARD for an example.
This PR implements that support, and sets the source to `KeyEventDeviceType.keyboard` for platforms that don't provide this information. The main thing it does is add the enum `KeyEventDeviceType`, and a new field `KeyData.deviceType`.
## Related Issues
- https://github.com/flutter/flutter/issues/136419
## Tests
- Updated tests to also read/write/verify this property.
The Dart code has the following declaration:
```dart
@Native<Void Function(Pointer<Void>, Handle)>(symbol: 'PictureRecorder::endRecording')
external void _endRecording(_NativePicture outPicture);
```
=> Dart doesn't expect to get a return value, so C++ shouldn't return
anything.
As part of eliminating the Flutter buildroot
(https://github.com/flutter/flutter/issues/67373), we are moving all
third-party dependencies from //third_party to //flutter/third_party.
Once all third-party dependencies have been migrated, tooling and config
will be moved and the buildroot will be eliminated altogether.
No tests changed because there is no semantic change to this PR. This is
simply relocating a dependency.
