@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
Splits FlutterPlatformViews.mm into the primarily C++ class FlutterPlatformViewsController/Pool/Overlay and all of the touch interceptor / gesture stuff.
Renames FlutterPlatformViewsController to PlatformViewsController, because, you know.
Renames FlutterPlatformViewLayer and FlutterPlatformViewLayerPool to OverlayLayer and OverlayLayerPool
Remove the need to merge raster and platform thread in the presence of platform views by defering UIView mutation and presentation of flutter views into separate platform thread task. Fixes priority inversion problem cause by platform thread blocking on drawable aquisition.
Open questions:
* Fixed ~What is a better interface for handling the partial submit with impeller. (TBD)~
* Fixed ~Update: We Don't | How do we fix this for Skia~ Fixed
* Fixed ~Update: Done, we post a task to the platform thread. Is there a shorter term solution for creating overlay layers on the raster thread.~ Fixed
* Fixed ~Update: seems to. Does this perform well enough (independent of platform/ui thread merge and w/ thread merge).~ Fixed
Fixes https://github.com/flutter/flutter/issues/142841
part of https://github.com/flutter/flutter/issues/150525
Previously this was using a zero EGLConfig handle in tests which use an AndroidContextGLImpeller that creates EGL surfaces. This apparently worked with older emulators, but the API 35 system image requires a real EGLConfig.
See https://github.com/flutter/flutter/pull/152498
Reverts: flutter/engine#54219
Initiated by: jonahwilliams
Reason for reverting: incorrect rendering on last frame after platform view is removed.
Original PR Author: knopp
Reviewed By: {jonahwilliams}
This change reverts the following previous change:
Currently we force full repaint when thread merging is detected, but that is not a good way to determine whether platform view is in hierarchy when thread merging is no longer needed. Alternative solution here makes the PlatformViewLayer force full repaint when diffing.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
The rasterizer class doesn't actually do anything besides call impeller::Surface to get the render target. lets just remove it. Simplifies refactores needed to make https://github.com/flutter/engine/pull/53826 work well.
Developers can control the backend in the following ways:
* **Do nothing**: Impeller with Vulkan is used where Vulkan is available with a fallback to Skia with OpenGL.
* **In `AndroidManifest.xml`, specify `io.flutter.embedding.android.EnableImpeller` as `false`**: Skia with OpenGL is used.
* **On the command line, specify `--no-enable-impeller`**: Skia with OpenGL is used.
Manifest options will take priority command line options when there is a conflict. This matches iOS behavior per https://github.com/flutter/flutter/issues/124049 (closed as WAI).
Fixes https://github.com/flutter/flutter/issues/149360
GLArea.has-alpha defaults to false, which makes it impossible for a Flutter app to be transparent.
The additional change to glClearColor is to prevent a black flash when the application starts, before Flutter widgets become visible. This will also affect applications that aren't transparent, by showing the default GTK background color instead of black. This will not make the window transparent, because the developer currently has to add some code to their `linux/my_application.cc` to support transparency.
Fixes flutter/flutter#152154
Transparent windows were possible before #50754. Would it be ok to add a test for this to prevent breaking transparency again in the future?
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
SurfaceTextureGetTransformMatrix returns a col-major 4x4 matrix. We used to convert it to a 3x3 matrix. Then when applying the transformation in the shader, I'd convert it back to a 4x4 matrix.
Instead of all this (potentially lossy) flip-flopping, store the matrix just as we get it in 4x4 form and perform the conversion just once if necessary. Today, it is necessary only in the Skia backend. SkM44 already has a converter to convert to and from a 3x3 SkMatrix. So, use that instead of rolling our own.
I spent a lot of time debugging these conversions and transformations because we had rolled our own and the printers seemed to dump in row-major order irrespective of storage order. This caused a lot of confusion.
No change in functionality. Hopefully, the next person debugging transformations has an easier go at this.
*Replace this paragraph with a description of what this PR is changing or adding, and why. Consider including before/after screenshots.*
*List which issues are fixed by this PR. You must list at least one issue.*
*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
