I've found a few instances where Vulkan worked correctly but surface control did not. lets add a debugging flag we can ask folks to try to narrow down the issue.
Part 1/5 for re adding tests documented in flutter/flutter/issues/154746
## 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.
- [ ] I updated/added relevant documentation (doc comments with `///`).
- [x] I signed the [CLA].
- [x] All existing and new tests are passing.
We're seeing issues with and "und" (undefined) locale and exceptions in
applications (see https://github.com/ubuntu/app-center/issues/1659). It
seems the GLib method for getting the language names doesn't clean up
invalid values, so we should do that.
The engine has historically used `package:litetest`, a home grown invention that is a wrapper around the Dart SDK.
In https://github.com/flutter/flutter/issues/133569, we've moved over to the heavier weight `package:test`, which has been simplified since first evaluated by the Dart SDK vending the dependencies we need. The last user of `package:litetest` is a single test in the Fuchsia SDK, `zircon_tests`.
This PR migrates the test from `litetest` (which will be deleted) to the Dart SK vendored `async_minittest`. For this simple test case, there is only a 1-line behavioral change (`notEquals(foo)` becomes `!= foo, true`), and it allows us to remove dependencies from the tree.
Skia is changing how it handles its internal copy of Vulkan headers to
prevent them from accidentally leaking to users and potentially
overriding the user's Vulkan headers. Users of Skia are responsible for
providing the Vulkan headers when including Skia's public Vk headers.
This change only includes Skia's public Vk headers when Flutter is
providing the Vulkan headers.
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.
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
@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...
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
