This is a re-land of https://github.com/flutter/engine/pull/55006, except that we special case the navigation channel to immediately dispatch its message if the isolate is not yet running.
This preserves the existing behavior relied upon by several iOS add2app tests, as well as the still used embedder v1 - and potentially undicovered future embedders.
Reverts: flutter/engine#55006
Initiated by: jonahwilliams
Reason for reverting: still failling mac module test
Original PR Author: jonahwilliams
Reviewed By: {jason-simmons}
This change reverts the following previous change:
Reland of https://github.com/flutter/engine/pull/54975
Fixes the initial route behavior for iOS. Previously the initial route setting would _always_ be posted as a task, which after merging the threads would fire after isolate creation, thus it would not actually update the initial route setting. Fixed Engine constructor so that it reads the initial route from the settings.
Reland of https://github.com/flutter/engine/pull/54975
Fixes the initial route behavior for iOS. Previously the initial route setting would _always_ be posted as a task, which after merging the threads would fire after isolate creation, thus it would not actually update the initial route setting. Fixed Engine constructor so that it reads the initial route from the settings.
Wean the DlOpReceiver interface and implementations off of using the SkScalar, Sk[I]Rect, and SkPoint objects in favor of our own DL/Impeller versions.
The start of an ongoing effort to eventually compartmentalize all use of Skia interfaces into a single backend rendering module that is one of 2 semi-pluggable renderers.
Reverts: flutter/engine#54975
Initiated by: jtmcdole
Reason for reverting: I believe this change caused flutter/flutter to break in an engine roll. It was one of two changes - the other being a webui change.
Tests broken:
module_test_ios: testDualCold
router test:
```
[2024-09-05 17:43:20.837343] [STDOUT] stderr: [ +135 ms] VMServiceFlutterDriver: Connected to Flutter application.
[2024-09-05 17:43:20.841927] [STDOUT] stdout: [ +4 ms] 00:00 [32m+0[0m:
Original PR Author: jonahwilliams
Reviewed By: {jason-simmons, johnmccutchan}
This change reverts the following previous change:
If we use runNowOrPostTask on platform channel responses, then we may not wake up the dart message loop. If nothing else wakes it up, then the embedder may hang on platform channel responses.
This fixes several google3 integration tests when run in merged thread mode.
If we use runNowOrPostTask on platform channel responses, then we may not wake up the dart message loop. If nothing else wakes it up, then the embedder may hang on platform channel responses.
This fixes several google3 integration tests when run in merged thread mode.
It turns out that when there are multiple paths to clip, they are unioned together, rather than intersected. But clipping paths need to be intersected.
There isn't any good way to intersect arbitrary paths. However, it is easy to intersect rect paths, which is the most common use case. Then we simply fallback to software rendering if we have to intersect non-rect paths. That is:
**Case 1** Only 1 clipping path (either rect path or arbitrary path):
Hardware rendering. This should be the most common use case
**Case 2** Multiple rect clipping path:
Hardware rendering. This is also common, and it's the linked issue that we are fixing.
**Case 3** Other complex case (multiple non-rect clipping path)
Fallback to software rendering. This should be rare.
After https://github.com/flutter/engine/pull/53826, we don't have a working benchmark that measures the main thread anymore. However, this PR shouldn't impact our ad benchmark, since it only has 1 clipping path. I will verify manually by checking Instruments and make sure no software rendering is happening. But we really should make the benchmark working again, not just for performance improvement, but also for monitoring regression.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/153904
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes https://github.com/flutter/flutter/issues/154103
From local testing, the Adreno 630 returns VK_INCOMPLETE when compiling certain shaders with no other error messages. That is not a valid return code from vkCreateGraphicsPipeline and likely indicates severe problems with the driver.
As of f20, fuchsia.scheduler.RoleManager is preferred over fuchsia.media.ProfileProvider. The Vulkan ICD uses fuchsia.scheduler.RoleManager and is loaded into the flutter component, so the component needs to use the fuchsia.scheduler.RoleManager protocol.
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/153591
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Use default mouse event handling behaviour on macOS 13.3.1 onwards. This has two positive effects:
* Avoids the workaround on newer macOS versions where it's unnecessary, thereby giving us confidence that the underlying AppKit issue is fixed and the whole method can later be removed.
* Will be caught by tooling when we drop support for versions of macOS prior to the fixed version.
Issue: https://github.com/flutter/flutter/issues/154063
Issue: https://github.com/flutter/flutter/issues/115015
No tests modified since there is no semantic change, either on versions of macOS where the issue is fixed (and thus the default event handler is correct) or on versions where it is not (and we still use the workaround).
Re-tested manually with the reduced transparency setting on macOS 14.6.1.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Fixes text input edit rotor accessibility missing edit actions.
It also fixes a few edit items that is displayed where it's not supposed to. (e.g. displaying select item while nothing to select).
*List which issues are fixed by this PR. You must list at least one issue.*
Fixes https://github.com/flutter/flutter/issues/151029
*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
Still needs to be tested in metalless environment. This should probably print out some kind of error message that tells folks that this is WAI, but I'm not sure if that would be too disruptive for g3.
Fixes https://github.com/flutter/flutter/issues/153883
Fixes https://github.com/flutter/flutter/issues/153623
Fixes https://github.com/flutter/flutter/issues/153788
* Avoids slow CPU resizer
* Avoids us having to write any code at all to resize these images
* Avoids reading from the GPU staging buffers that are not read cached (similar to Glyph cache performance issues).
Also changes the single frame codec upload to either use the device private storage path or to defer upload until the GPU returns. This allows us to ensure that mips are always constructed and makes sure that we don't need to keep around the CPU texture reisze that depends on the Skia software backend.
Separately, I updated the deferred task system to allow separate success/failure tasks to make it easier to track the final state.
@matanlurey:
> As of 2f6952657d, we are now printing a `W/FlutterView( 7775): API level 34 is too low to query bounding rects.` message which is not user actionable. Was this intended to stay in the merged PR? What value is it supposed to have?
@yaakovschectman:
> You might be right about that
Some android devices have only a single fast core. We set the threading affinity for UI/Raster to the fast core, which can lead to the UI/Raster being serialized on this thread. Instead, we should weaken /invert the affinity to "Not slow cores".
FIxes https://github.com/flutter/flutter/issues/153690
Customer money will see some benchmark regressions but they can deal.
Original Title: Add FlutterViewDelegate and BoundingRect methods
Check the bounding rect for caption bar when sending viewport metrics to
Flutter to account for freeform mode. Use the more recent
`getBoundingRects` over `getInsets`.
Tests will need to be kept separate until Robolectric publishes a
version that supports API level 35.
Roboletric tests for this pr will be part of google testing until then.
Pr for tests here https://critique.corp.google.com/cl/657302386.
https://github.com/flutter/flutter/issues/146658
## Pre-launch Checklist
- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide] and the [C++,
Objective-C, Java style guides].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I added new tests to check the change I am making or feature I am
adding, or the PR is [test-exempt]. See [testing the engine] for
instructions on writing and running engine tests.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I signed the [CLA].
- [x] All existing and new tests are passing.
Make sure the old dispatcher cannot be used if the new dispatcher is enabled. Migrate tests using old canvas to new canvas, mostly to make deleting the old one easier...
The first part of switching Impeller/Aiks to using the display list instead of re-recording rendering operations. This should eventually let us cut CPU overhead of the raster thread for complex applications, though it should have no impact on GPU performance.
This does introduce a GLES only rendering bug that I haven't had luck tracking down, but is almost certainly due to switching to DL computed depth values. I'd like to handle this as a follow up when we prioritize GLES. https://github.com/flutter/flutter/issues/153504
Part of https://github.com/flutter/flutter/issues/142054
Fixes https://github.com/flutter/flutter/issues/153335
When platform views are present, we always repaint entire frame. We must pass the buffer damage all the way to `GPUSurfaceMetalSkia/GPUSurfaceMetalImpeller` so that they know that the other two surfaces are lagging behind front surface and need to be repainted.
This is currently not being done with platform view present, that's why we miss full frame repaint when removing platform view.
With this merged in, it should be safe to reland https://github.com/flutter/engine/pull/54537 without any changes.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This improves Flutter Window's texture format logic:
1. **If the device has extension `GL_EXT_texture_format_BGRA8888`**: backing stores' texture will be created with format `GL_BGRA_EXT` instead of `GL_RGBA8`. This is what fixes https://github.com/flutter/flutter/issues/150546.
2. **Otherwise**: backing stores' texture will be created with format `GL_RGBA` and the engine will use the color type `kRGBA_8888_SkColorType` when creating the `SkSurface`.
Previously the engine always used color type `kN32_SkColorType`, which could be either RGBA or BGRA depending on the machine that compiled the engine. This caused Skia validation errors as the texture's format did not match the Skia surface's color type.
I tested this by editing Flutter Windows to force it down this code path.
Huge kudos to @chinmaygarde for the OpenGL expertise!
Fixes: https://github.com/flutter/flutter/issues/150546
> [!WARNING]
> Unfortunately, we are unable to test this.
> This bug appears to only affect older devices; none of our devices reproduce this issue.
> We also do not have the infrastructure to do a native screenshot test on Windows.
> I will get a test exemption for this change.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Reverts flutter/engine#54453
Not quite ready to remove Impeller Scene yet because I'm still porting
the animation functionality. Keeping it around allows me to switch back
and forth to compare without having to recompile the engine.
Over a month ago I said something like "we can revert this a couple of
weeks from now" in one of the Impeller meetings. But for better or worse
(better, I think), I ended up spending a ton of time trying to make the
PBR good first (which doesn't exist in this C++ version).
We used to require this only on iOS because the standard library till iOS 9 didn't have support for this. We have moved past that version. No change on other platforms.
Allows using an EGL surface as a flutter backing store. Way more convenient for GBM than hacking gbm bo's into GL FBOs.
This resolves https://github.com/flutter/flutter/issues/58363
Currently, the embedder API assumes that the compositor (if it exists) will let flutter render into FBOs or Textures and then composite the whole thing onto the actual (EGL) window surface. I think this assumption is also documented a bit in https://github.com/flutter/flutter/issues/38466
However, in my case, I want let the hardware do the composition (using the linux KMS API), and render each flutter layer into it's own EGL surface.
It's possible to hack around this by creating your own GBM BOs, importing those as EGL images, then importing those as GL Render Buffers and attaching those to GL FBOs and that works (tested it). However, that's basically reimplementing 50% of the whole GBM/EGL "window" system integration for no reason.
This PR adds:
1. To the embedder API:
- a new kind of OpenGL Backing store: `FlutterOpenGLSurface`
- consisting of just a `make_current` and destruction callback (plus userdata)
- the make_current callback should make the target surface current, i.e. `eglMakeCurrent(..., surf, surf)`
- will be called by the engine before rendering onto the backing store
2. Some wiring to call make_current before rendering into the backing store
## TODO:
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
