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.
All render targets created by flutter have a single color attachment. Lets specialize that case in impeller::RenderTarget by creating a field for that attachment description instead of placing it in a hashmap.
Should fix https://github.com/flutter/flutter/issues/159520 ~~but I still need to check locally.~~ Seems to do the trick.
All cmd bindings were copying the shader metadata, which meant allocating/de-allocating a lot of strings per draw.
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 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.
Fixes https://github.com/flutter/flutter/issues/158963
If the GLES version is at least 3, then we can attach a sync fence to the texture gles object. If this operation succeeds, then we can use gl.Flush instad of gl.Finish. Then, when binding the texture - if a sync fence is present we wait and then remove the fence.
This addresses https://github.com/flutter/flutter/issues/159088
If the image is rotated in its exif data, the coded width/height may differ from the display width/height. It's important to use the display width/height so that `texImage2D` does the right thing with the `VideoFrame`.
Threads that add operations to the ReactorGLES assume that those operations will be executed serially.
But prior to this change, the ReactorGLES added all operations into one queue. The reactor would then execute those operations on any thread that can react. This could cause operations that were added to the reactor on the raster thread to be submitted to the GPU on the IO thread (or vice versa).
The reactor does not wait for the GPU to finish execution of those operations. So other operations added on the raster thread could be submitted by a reaction before the GPU has completed the operation that was submitted on the IO thread.
This PR ensures that operations added to the reactor on a given thread will be executed during a reaction on that same thread. If the thread can not currently react, then the operations will be queued until the thread enables reactions.
This also adds a call to CommandBuffer::WaitUntilScheduled to ImageDecoderImpeller. This ensures that the command buffer submitted on the IO thread is flushed before the image is returned.
Fixes https://github.com/flutter/flutter/issues/158535
Fixes https://github.com/flutter/flutter/issues/158388
Fixes https://github.com/flutter/flutter/issues/158390
Flutter_tester has a task observer that checks whether the test's Dart code has finished execution. If Dart no longer has live ports but does have pending microtasks, then flutter_tester should continue running and force a drain of the microtask queue.
Fixes https://github.com/flutter/flutter/issues/158129
By splitting all large fallback fonts (1MB+) into smaller parts, we get faster downloads and fast decoding.
Some fonts are split into 100+ parts, and that's causing `main.dart.js`'s size to grow by ~47KB (Brotli-compressed). The increase in size is due to the extra data we have to store about all the parts of these fonts.
The PR also makes changes to ensure we don't download the same license file 100 times (once for each part of the split font).
Fixes https://github.com/flutter/flutter/issues/138288
Part of https://github.com/flutter/flutter/issues/153974
Copy-pasta docs:
```
/// Creates an image filter from a [FragmentShader].
///
/// The fragment shader provided here has additional requirements to be used
/// by the engine for filtering. The first uniform value must be a vec2, this
/// will be set by the engine to the size of the bound texture. There must
/// also be at least one sampler2D uniform, the first of which will be set by
/// the engine to contain the filter input.
///
/// For example, the following is a valid fragment shader that can be used
/// with this API. Note that the uniform names are not required to have any
/// particular value.
///
/// ```glsl
/// #include <flutter/runtime_effect.glsl>
///
/// uniform vec2 u_size;
/// uniform float u_time;
///
/// uniform sampler2D u_texture_input;
///
/// out vec4 frag_color;
///
/// void main() {
/// frag_color = texture(u_texture_input, FlutterFragCoord().xy / u_size) * u_time;
///
/// }
///
/// ```
///
/// This API is only supported when using the Impeller rendering engine. On
/// other backends a [UnsupportedError] will be thrown. This error can be
/// caught and used for feature detection.
```
Fixes https://github.com/jonahwilliams/flutter_shaders/issues/34
Fixes https://github.com/jonahwilliams/flutter_shaders/issues/26
Fixes https://github.com/flutter/flutter/issues/132099
This change doesn't have unit tests, because it doesn't actually change the functional behavior of the renderer, it only changes its performance characteristics. If the transfer list is not included, the browser copies the image bitmaps instead of transfers them, which is slow, but does actually work. I am going to be adding some additional benchmarking in the framework to ensure that we detect if we regress something like this again.
This relands the [reverted](https://github.com/flutter/engine/pull/55993) [original PR](https://github.com/flutter/engine/pull/55747) with one important adjustment: if the header is empty and has a label, it is rendered as a heading (`<h1>`, `<h2>`, etc) instead of a `<header>`. This is to be consistent with mobile, where headers are frequently used as headings, and screen readers do indeed read it as "heading". Changing all headers to the `<header>` tag turned to out to be too disruptive to existing usages of `SemanticsProperties.header`.
Long-term, when https://github.com/flutter/flutter/issues/155928 is implemented, we could migrate the framework to use `SemanticsProperties.headingLevel` to communicate that something is a heading, and encourage our users to move from `header` to `headingLevel` as well. After that migration is done, we could make all headers proper `<header>` tags, and not special-case empty headers.
Fixes https://github.com/flutter/flutter/issues/152268
If our operation affects the backdrop, the layer slice builder needs to take that into account when deciding whether to actually build a slice. In addition, we should take the content in the backdrop into account when calculating the cull rect for our picture recorders.
For this to actually work, we need a fix for https://g-issues.skia.org/issues/362552959 which I am currently working on.
Google Fonts serves TTF fonts gzipped. By switching to WOFF2 fonts, we get Brotli compression by design.
Google Font's WOFF2 fonts are 30%+ smaller than their gzipped TTF counterparts (including Roboto).
This PR fixes https://github.com/flutter/flutter/issues/156223.
**Problem:** The issue above only occurred when using stylus on Web. Multiple touches were treated as different devices: new devices were added and former devices that had the pointer lifted were never removed. This was further caused by the design that Flutter uses JS's `PointerEvent.pointerId` as the device ID, which increases for each touch.
Flutter had to use `PointerEvent.pointerId` because JS doesn't provide a way to distinguish between multiple styluses. This PR fixes this issue by simply supporting only one stylus, since support for multi-stylus can be really hard. How multi-stylus should be supported can be discussed upon such demands in the future, but at least for now, iPad doesn't support multi-stylus and it's not something I can test.
This PR also rewrote some comments that I got confused by while reading the code.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The `safeBlur`/`safeRemove`/`safeRemoveSync` methods in the view manager should become the standard way to "blur" and "remove" elements within the web engine.
Calling these method ensures the blur operation doesn't disrupt the framework's view focus management because these methods transfer the focus from the current element to its containing EngineFlutterView's `rootElement`, so focus never abandons the Flutter view unless the user wants to.
This is a generalization of the former `DefaultTextEditingStrategy.scheduleFocusFlutterView`, which turns out is needed in anything that touches elements that may receive focus in the engine, not just text editing.
## Issue
(Maybe) Part of https://github.com/flutter/flutter/issues/157387
(Opportunistically) Fixes https://github.com/flutter/flutter/issues/46638
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
When dart2wasm was still in early stages and unstable, we wanted to run dart2wasm on as many unit tests and code paths as possible. However, dart2wasm is much more stable now, and there are some configurations that users simply cannot not use and are not worth testing. Specifically, users cannot use renderers other than skwasm with dart2wasm, so we should avoid running test suites specific to those renderers.
* `dart2wasm-html-html` and `dart2wasm-canvaskit-canvaskit` bundles and their associated suites are removed. These are tests specifically for the `html` and `canvaskit` renderers, which are run with those renderers. Users can't use these renderers in dart2wasm mode, so it's not useful to run these tests.
* `dart2wasm-html-ui` and `dart2wasm-canvaskit-ui` and their associated suites are also removed. These are tests that can run on any renderer, and they are being run with the `html` and `canvaskit` renderers. We don't need to run against these renderers on `dart2wasm` since users can't actually use these renderers in dart2wasm mode.
* Notably, `dart2wasm-html-engine` and associated suites are staying. These run against the `html` renderer, but only incidentally. These tests are supposed to be exercising logic that doesn't actually pertain to rendering, and it's logic that will be running for the end user in dart2wasm mode. So it makes sense to continue running these tests against dart2wasm.
This attempts to reland the single-threaded Skwasm PR: https://github.com/flutter/engine/pull/56206
The main changes here are in the second commit:
* We need to actually bundle the `skwasm_st` artifacts in `flutter_web_sdk.zip`
* The `locateFile` hack no longer works since emscripten doesn't actually create a worker.js file anymore. So instead, that has been modified to use the `mainScriptUrlOrBlob` module API to do a very similar hack.
Note: I did presubmit testing with the framework CI and it appears the pertinent tests pass. See https://github.com/flutter/flutter/pull/157967
Reverts: flutter/engine#56206
Initiated by: jonahwilliams
Reason for reverting: failing to roll into framework: https://github.com/flutter/flutter/pull/157919
Original PR Author: eyebrowsoffire
Reviewed By: {harryterkelsen}
This change reverts the following previous change:
This PR creates a single-threaded version of the skwasm renderer, appropriate for non-crossOriginIsolated browsing contexts.
* The single threaded renderer is essentially the same as the multi-threaded renderer, except instead of spawning a web worker and posting messages to it, it simply schedules microtasks on the main thread in their place.
* The new renderer is vended as `skwasm_st.js` and `skwasm_st.wasm` in the same location as multithreaded skwasm. In order to properly build and function, we needed some fixes I put into emscripten that landed in version 3.1.70. That version also changed some behavior that required a few fixes to the CanvasKit build files.
* The skwasm loader in flutter.js has been modified to use the skwasm_st variants when encountering a non-crossOriginIsolated context but a browser and configuration that otherwise would allow the use of skwasm. I also added a new `forceSingleThreadedSkwasm` option to the flutter configuration so that we can override this behavior, especially so that we can accurately benchmark the single threaded renderer in a crossOriginIsolated environment.
* I also consolidated a bunch of our shards that run tests to just have one per browser/platform combination, so four total. This will address https://github.com/flutter/flutter/issues/124682
This PR creates a single-threaded version of the skwasm renderer, appropriate for non-crossOriginIsolated browsing contexts.
* The single threaded renderer is essentially the same as the multi-threaded renderer, except instead of spawning a web worker and posting messages to it, it simply schedules microtasks on the main thread in their place.
* The new renderer is vended as `skwasm_st.js` and `skwasm_st.wasm` in the same location as multithreaded skwasm. In order to properly build and function, we needed some fixes I put into emscripten that landed in version 3.1.70. That version also changed some behavior that required a few fixes to the CanvasKit build files.
* The skwasm loader in flutter.js has been modified to use the skwasm_st variants when encountering a non-crossOriginIsolated context but a browser and configuration that otherwise would allow the use of skwasm. I also added a new `forceSingleThreadedSkwasm` option to the flutter configuration so that we can override this behavior, especially so that we can accurately benchmark the single threaded renderer in a crossOriginIsolated environment.
* I also consolidated a bunch of our shards that run tests to just have one per browser/platform combination, so four total. This will address https://github.com/flutter/flutter/issues/124682
