This change converts it from an events that spans a time interval
to an event that occurs at an instant.
We also emit this trace event when there is no lag as opposed to
only when there was a lag to make it monotonous.
Co-authored-by: Kaushik Iska <kaushikiska@google.com>
This event goes from now -> current vsync target time
to avoid the limitations as seen in https://github.com/flutter/flutter/issues/54095#issuecomment-610636237
This event also tags additional metadata to capture
`vsync_transitions_missed` considering the refresh rate of the display.
This change also adds TimeRecorder which records time at the start
of each frame to capture the latest vsync target display time and
wires it in to the rasterizer to add trace events when there is a lag.
* "Reland Clang 11, roll buildroot to 1bc40a5f916adb93d87e2a2230a0ec43db876c1c, take 4 (#17467)" (#17482)"
This reverts commit 8166a91bca11b83c16fba8f8fd407e937a2ac89c.
* format code
* Roll buildroot to 3a27de1c5bb0f50be7d3efe3e00de4f6068c9f30
This PR touches variable names, class names, and file names so it's significantly more risky than its predecessor https://github.com/flutter/engine/pull/17329
Due to file name changes, this PR is expected to change the license files.
We haven't rename `shell/gpu` to `shell/raster` yet. It should be optional but I think it's better to have `raster_surface_software.cc` than `gpu_surface_software.cc`.
This lets us measure stats on when the frame was
scheduled to be rendered vs when it finished rasterizing.
Note: This isn't propagated to the FrameTimings struct yet,
that is to be followed.
Fuchsia benchmarks depend the name being precisely "vsync callback".
Since this is causing immediate build issues, change it back to "vsync
callback" on Fuchsia. Stronger testing for this in the long run is
currently under discussion.
b/150902962
This moves the Metal `GrContext` creation utilities from `GPUSurfaceMetal` into
a separate `IOSContext` object subclass. An analogue of this object was used in
the GL regime for the management of onscreen and offscreen contexts that were
not tied to the lifecycle of the `GPUSurface`. This pattern has now been
generalized for use with all backends that need a resource context
(`IOSContextGL` and `IOContextMetal`).
The platform views controller management in the `ExternalViewEmbedder` interface
implementation was repeated three times for [Metal][metal], [OpenGL](opengl) and
[Software](software) rendering. This repetition has been removed and a single
implementation present in the base `IOSSurface` and used on all platforms.
Addition of new client rendering APIs should not affect how the engine renders
into the platform view interleaving levels.
All rendering API selection logic has been moved into a single set of utilities
in `rendering_api_selection.h`. This enables the removal of a lot of code blocks
guarded by `FLUTTER_SHELL_ENABLE_METAL`. The remaining uses of this will be
removed when unified builds are enabled.
The Metal backend now also adds traces similar to the GL backend.
The `IOGLContext` has been renamed to `IOContextGL` to be more in line with the
convention used in this library.
Fixes https://github.com/flutter/flutter/issues/41827
Adds https://github.com/flutter/flutter/issues/52150
[metal]: 1194ba2b21/shell/platform/darwin/ios/ios_surface_metal.mm (L55)
[opengl]: 1194ba2b21/shell/platform/darwin/ios/ios_surface_gl.mm (L95)
[software]: 1194ba2b21/shell/platform/darwin/ios/ios_surface_software.mm (L146)
Chrome Trace viewer treats events labeled "VSYNC" as special and highlights them (when the "Highlight Vsync" checkbox is enabled). Ideally VSYNC events are generated by the host system at their source. System VSYNC events are indeed present in full-system systraces. Flutter-level traces (as seen in Observatory/Flutter devtools) do not contain the system VSYNC events, so we rely on the engine to generate them (as close to where they would be generated by the system ideally).
Currently the common (platform-independent code) generates VSYNC events at the time when the UI thread starts processing a frame. This has two drawbacks:
1. The traces are generated with a delay (we wait for the callback to be have been scheduled on the UI thread instead of tracing as soon as the system notified us.
2. When inspecting system-wide traces we'll have both the system and the Flutter app (or potentially multiple Flutter apps) generate VSYNC events at the same time. This confuses both the developers and the trace viewer.
This change moves the VSYNC event generation to the platform-specific embedder implementations:
1. On Android/iOS we always generate the VSYNC event since Android/iOS developers use Flutter tools to debug the apps.
2. On Fuchsia we do not generate VSYNC events since the systraces always contain them.
3. In the Embedder wrapper we don not generate VSYNC events and rely on the actual embedder to do this in a way appropriate for the target system.
This reverts commit ef9e7b1a1365c07ab0df2e2016c4442c3963c2c7 with the following changes to accommodate an embedder for whom the original optimizations caused issues:
* Ensure stable order in the backing stores presented to the embedder. This is a pessimization that will be reverted when the embedder migrates. Tracked in https://github.com/flutter/flutter/issues/51228
* Forego the optimization where the unused layers would be collected before allocation of new layers needs to happen. This is a pessimization that will be reverted when the embedder migrates. Tracked in https://github.com/flutter/flutter/issues/51229
More context in b/146142979.
This change creates a test only implementation of flutter::Surface backed by an
offscreen Vulkan GrContext. Much of the code in this test Surface was lifted
from flutter::VulkanWindow which I was unable to use without extricating it
from the VkSurface/VkSwapchain code which we do not want to use in offscreen
tests. I would recommend refactoring VulkanWindow to separate GrContext
creation and VkSwapchain creation in order to promote greater code reuse
between onscreen and offscreen vulkan paths.
This change is excersised thoroughly by the shell tests and was manually
tested against these tests on Fuchsia on Intel.
This was already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
See go/dart-10x-faster-async for more information.
[0] https://github.com/flutter/flutter/commit/347823234fd
