* Removed virtual destructor. We only use Geometry types with std::shared_ptr which remembers the correct dtor, we'd only need the virtual destructor if we were using `free` ourselves.
* Remove std:unique_ptr. We had a mix on unique and shared ptrs, and were even doing some copies/conversions between the two. I made it consistently shared_ptr, I don't see the advantage of unique given that geometries are essentially immutable.
* made geometry classes have more const methods and final.
* Added some asserts on trivial destruction.
- `FlutterViewEmbedder` doesn't create the DOM tree anymore (instead, `DomManager` does).
- `DomManager` only creates the DOM tree (with styles) but doesn't insert it into the document.
- `EngineFlutterView` takes the root element from `DomManager` and inserts it into the document.
- We finally can now create multiple Flutter views, each with its own DOM tree.
cc @yjbanov since I'm making a few changes that probably conflict with your semantics changes.
Part of https://github.com/flutter/flutter/issues/134443
Part of https://github.com/flutter/flutter/issues/137447
The emulator tests I added yesterday are failing because the systrace python test script uses features introduced in API 29, which causes the `perfetto` invocation to fail.
It's not essential that we run this test on lower API levels, so instead I'm making the script bail out in this case.
Other than that, the shard seems to be consistently passing, so I'm removing bringup.
A partial implementation of the new gaussian blur effect. This should perform enough of the code to start getting some performance numbers.
Known outstanding problems:
1) The edges of the blur are clipped. I have notes on how I plan on expanding render space in the PR.
1) Animating the sigma causes some "jumping around artifacts" resulting from the downsampling (maybe the discrete nature of texture pixel size?)
1) Coverage hints are ignored. I think depth tests will make that not much of an issue.
1) We aren't ping ponging textures yet
1) The snapshot's transform is ignored.
issue: https://github.com/flutter/flutter/issues/131580
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Had not used std::adopt_lock before and didn't realize that the unique lock destructor unlocks the mutex even when the mutex is adopted (which I suppose makes sense when you think about it). But I had added the annotations assuming the lock will remain if adopted. Found after a painful round of debugging the "safe" condition variables.
Allow creating a TextureMTL instance that is backend by a CAMetalLayer, which only acquires the drawable (and texture) lazily.
I split TextureMTL into two subclasses, one that has the standard wrapping behavior of a MTLTexture, and the other that holds a drawable. This is part of the foundational work for "removing drawable acquisition latency", as we need to delay aquisition of the drawable texture to a worker thread.
The drawable backed texture is only used in tests for now.
Part of https://github.com/flutter/flutter/issues/138490
In cases where we subclassed gtest fixtures purely to get better naming for test output (i.e. displaying/filtering on AccessibilityBridgeMacTest instead of AutoreleasePoolTest, replace these with `using` declarations, which is equally effective and avoids actually subclassing.
This applies no semantic changes to the code or tests.
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
Platform Views on Android require API 29 when using Vulkan.
~~I'm not sure if I did the CI changes right, want to run it here and see. The added test needs to run on a device or emulator with API 29 or above and API 28 or below to be valid.~~
Makes the following changes to CI:
- Runs the emulator tests on presubmit, but only if `shell/platform/android/**` or `lib/ui/**` or `.ci.yaml` changes.
- Changes the emulator tests to be a regular engine_v2 test that spawns an x86 build. Unfortunately, the older API level emulators are only available for x86, not x86_64, and you cannot run the binary we create unless it matches the ABI.
- Runs the new test on both API 28 and API 34.
Fixes https://github.com/flutter/flutter/issues/132984
/cc @johnmccutchan fyi
Runs all FlutterMenuPlugin tests in an AutoReleasepoolTest, which
ensures all allocations are cleaned up.
Also extracts out some hackery into the FlutterMenuPluginTest fixture to
ensure that NSApplication instantiates everything necessary to do menu
bar manipulation.
Also replaces the use of OCMock in FlutterMenuPluginTest.mm with a fake
FakePluginRegistrar class. This avoids unnecessary use of OCMock in the
tests, which has been responsible for flakiness in some tests, in
particular where the mock is used across threads. This test was not
problematic, but the fake makes the tests more readable.
Also fixes linter warnings about using NSLocalizedString for user-facing
strings.
Issue: https://github.com/flutter/flutter/issues/104789
Issue: https://github.com/flutter/flutter/issues/127441
Issue: https://github.com/flutter/flutter/issues/124840
Introduce weak_nsobject from chromium.
There are some usages of weak_ptr wrapping Objective-C ids, weak_ptr is not really designed for ids and such usages are blocking the arc migration.
This PR mostly copies the weak_nsobject from chromium, at the same hash that we copied the ARC/MRC compatible scoped_nsobject: fd625125b8
To match how we used weak_ptr for those ids, I made some changes to the weak_nsobject:
- WeakNSObjects needs to be generated by a WeakNSObjectFactory. The WeakNSObjectFactory is owned by the objc class and acts as the generator of the WeakNSObjects. All the WeakNSObjects' derefing thread should be the same of the WeakNSObjectFactory's creation thread.
- chromuim's WeakNSObjects can be detached from the thread and re-attached to a new thread. To match our weak_ptr behavior, I changed WeakNSObjects to be only accessed from a single thread, the same as weak_ptr
This PR also moves the FlutterEngine to use WeakNSObject and updated related classes.
part of https://github.com/flutter/flutter/issues/137801
[C++, Objective-C, Java style guides]: https://github.com/flutter/engine/blob/main/CONTRIBUTING.md#style
This is a requirement for the "Remove Drawable Acquisition Latency" Change, but is otherwise a harmless improvement.
---
Submitting a command buffer causes the backend specific encoding logic to run. Metal is unique in that it is fairly easy to move this work into a background thread, allowing the engine to move onto creating the next command buffer. This improves throughput of the engine, at the cost of needing two slightly different APIs. Currently the GLES and Vulkan versions of this method still submit synchronously - for now that is out of scope as doing background work with those APIs has proved more challenging.
See also:
* https://github.com/flutter/engine/pull/42028
* https://github.com/flutter/flutter/issues/131698
Separately, as a requirement for the design in "Remove Drawable Acquisition Latency", we need to be able to defer drawable acquisition to this background thread. While this almost already works for render passes, it does not work for blit passes today. if the engine renders a backdrop filter, then the final command buffer submitted will be a blit pass that copies an offscreen onto the drawable. Therefore we need to add an async version of the blit submission, so that we have a hook to move the drawable acquisition onto a background thread for metal.
This hadn't been done until now because most blit cmd buffers have 1 or 2 cmds on them so the benefit of moving to a background thread is minimal.
Part of https://github.com/flutter/flutter/issues/138490
The current way we are doing global styles (using `CSSStyleSheet`) forces us to insert the DOM element into the document before we attach any styles to the element. That restriction goes away if we append the styles as `TextNode`s into the `<style>` element.
Now with the movement towards `DomManager`, I would like to be able to create the entire DOM tree of the Flutter View (including all styles) before we insert it into the document.
Part of https://github.com/flutter/flutter/issues/134443
