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
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.
