Embedders can now notify shell during startup about the various displays and their corresponding settings.
Adds a notion of Display update type which can later include chages to displays during runtime such as addition / removal / reconfiguration of displays.
We also remove the responsibility of providing the refresh rate from `vsync_waiter` to `DisplayManager`.
Rewires existing platform implementations of the said API to use `Shell::OnDisplayUpdate` to notify the display manager of the startup configuration.
DisplayManager is also thread-safe to account for rasterizer and UI thread accesses.
## Description
As the related issue refer, the application may be doing too much work on its main thread even in a simple hello_world demo.
That is because the creation of `Engine` on the ui thread takes a noticeable time, and it is blocking the platform thread in order to run `Shell::Setup` synchronously.
The cost of `Engine`'s constructor is mainly about the creating of root isolate. Actually, there used to be another time-consuming process, the default font manager setup, which was resolved by https://github.com/flutter/engine/pull/18225.
Similar to https://github.com/flutter/engine/pull/18225, this pr move the creation of root isolate out from creating `Engine`. After this action, the main thread blocking is quite an acceptable slice.
## Related Issues
https://github.com/flutter/flutter/issues/40563 could be resolved by this pr.
Reland #19396 with a fix for improper scale that was affecting internal tests
Tested: Ran all unittests, ran internal tests, and ran workstation on Fuchsia
BUG: 53062, 53063
The fuchsia code around metrics and sizing was just sending this
information through a side-channel, when the engine already had the
information available. So, delete all of it to make future CLs simpler.
Additionally, the SceneUpdateContext has many unneccesary dependencies
re: metrics and PaintTasks. Break those to make future CLs simpler.
Tested: Ran all unittests and ran workstation on Fuchsia
BUG: 53062, 53063
This reverts commit 6ea69a0d4339dd153899bb6c299689f1dd43329d.
On top of the revert, it reverted a commit in the PR:
https://github.com/flutter/engine/pull/14024
This reverts commit ea67e5b0b930ebf552bc7dbd678a35ee6a129c39.
Remove dead shared snapshot arguments to Dart_CreateIsolateGroup.
6a65ea9cad4b [vm] Remove shared snapshot and reused instructions features.
db8370e36147 [gardening] Fix frontend-server dartdevc windows test.
4601bd7bffea Modified supertype check error message to be more descriptive.
0449905e2de6 [CFE] Add a serialization-and-unserialization step to strong test
c8b903c2f94f Update CHANGELOG.md
2a12a13d9684 [Test] Skips emit_aot_size_info_flag_test on crossword.
b26127fe01a5 [cfe] Add reachability test skeleton
Obtaining the SkiaUnrefQueue through the IOManager is unsafe because
UIDartState has a weak pointer to the IOManager that can not be dereferenced
on the UI thread.
The contents rendered into the backing stores are already correctly scaled.
The initial implementation assumed this also held true for the metrics obtained
via embedded view parameters.
Fixes b/142699417
Since this is currently only meant to be used by the embedding internally, the setter in Objective-C is only exposed via the FlutterDartProject private class extension. Unit tests have been added to the shell_unittests harness.
Fixes https://github.com/flutter/flutter/issues/37641
This reverts commit c2879cae2ee3707ad07af1118bf4862dc1d82bb7.
Additionally, we fix https://github.com/flutter/flutter/issues/40863 by adding a secondary VSYNC callback.
Unit tests are updated to provide VSYNC mocking and check the fix of https://github.com/flutter/flutter/issues/40863.
The root cause of having https://github.com/flutter/flutter/issues/40863 is the false assumption that each input event must trigger a new frame. That was true in the framework PR https://github.com/flutter/flutter/pull/36616 because the input events there are all scrolling move events. When the PR was ported to the engine, we can no longer distinguish different types of events, and tap events may no longer trigger a new frame.
Therefore, this PR directly hooks into the `VsyncWaiter` and uses its (newly added) secondary callback to dispatch the pending input event.
This reverts commit fcc4ab32301396986dd5103d6d444bff35fe0f63.
Fixes https://github.com/flutter/flutter/issues/41394 and other
related correctness issues.
TBR: @arbreng @jason-simmons @mehmetf
On Fuchsia, add a build flag for compositing OpacityLayers using the system
compositor vs Skia, which exposes a fastpath for opacity via Scenic.
This will only work under certain circumstances, in particular nested
OpacityLayers will not render correctly!
On Fuchsia, add a build flag for compositing PhysicalShapeLayers using
the system compositor vs Skia. Set to off by default, which restores
performant shadows on Fuchsia.
Remove the opacity exposed from ChildView, as that was added mistakenly.
Finally, we centralize the logic for switching between the
system-composited and in-process-composited paths inside of
ContainerLayer. We also centralize the logic for computing elevation
there. This allows the removal of many OS_FUCHSIA-specific code-paths.
Test: Ran workstation on Fuchsia; benchmarked before and after
Bug: 23711
Bug: 24163
* Fix broken tests
Additionally, we now use the engine directly as a delegate instead of storing potentially dead runtime_controller.
Unit tests have been updated to include an engine restart check which would fail before the fix.
This fixes https://github.com/flutter/flutter/issues/40303
The engine's activity_running flag tracks whether the app is in the paused or
running lifecycle state. The engine had been defaulting activity_running to
false (meaning paused). But the animator had been defaulting its paused flag
to false, which allowed frames to render at startup. If the engine loses and
regains its surface, then frames would stop rendering because activity_running
is false (even though frames had been rendering when the engine initially
acquired its surface).
This change puts the engine and the animator into a consistent state at
startup. Frames will continue to render until the embedder sends a lifecycle
message that will pause both the engine and the animator.
See https://github.com/flutter/flutter/issues/32624
