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.
This is a duplicate of flutter/engine#13360 with the test switched to use the software backend instead of the GL backend.
After some debugging and testing on another GL embedder I think the issue with the test is some bug having to do with the GL implementation in the test harness specifically.
Fixesflutter/flutter#38903
Previously the cache was disabled on whether or not PlatformViews were
globally enabled. Instead track their existence in the view hierarchy
and only disable RasterCache if a PlatformView is actually present.
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
This reverts commit ebb5b909fbb10dad2275acd4fc8ec1d9744a0bf6.
Seeing the following breakage on host build:
```
../../flutter/flow/scene_update_context.cc:205:36: error: non-const lvalue reference to type 'flutter::MutatorsStack' cannot bind to a value of unrelated type 'const flutter::Stopwatch'
frame.context().raster_time(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../flutter/flow/scene_update_context.cc:207:36: error: no viable conversion from 'flutter::TextureRegistry' to 'const flutter::Stopwatch'
frame.context().texture_registry(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../flutter/flow/instrumentation.h:55:32: note: candidate constructor not viable: no known conversion from 'flutter::TextureRegistry' to 'const flutter::Stopwatch &' for 1st argument
FML_DISALLOW_COPY_AND_ASSIGN(Stopwatch);
^
../../flutter/fml/macros.h:28:3: note: expanded from macro 'FML_DISALLOW_COPY_AND_ASSIGN'
TypeName(const TypeName&) = delete; \
^
../../flutter/flow/scene_update_context.cc:208:36: error: non-const lvalue reference to type 'flutter::TextureRegistry' cannot bind to a temporary of type 'flutter::RasterCache *'
&frame.context().raster_cache(),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../flutter/flow/scene_update_context.cc:209:36: error: cannot initialize a member subobject of type 'const flutter::RasterCache *' with an rvalue of type 'bool'
false};
^~~~~
```
At a quick glance, one could easily think of the "engine_time" as the
GPU thread time and the "frame_time" as the UI thread time because the
GPU thread time is mainly spent on the engine while the UI thread time
is mainly spent on the Dart framework to generate the frame.
But it's actually the other way. The "engine_time" is UI thread time and
the "frame_time" is the GPU thread time.
To avoid the confusion, rename them to "ui_time" and "raster_time"
respectively. I avoided the "gpu_time" because the rasterization may be
purely on a CPU backed software Skia backend.
The raw pointer isn't a reliable id as the allocator can reuse an
address that's just been released for another layer.
This will fix Fuchsia bug FL-216.
This problem was not affecting non-Fuchsia Flutter probably because
non-Fuchsia Flutter purges the raster cache key much more frequently so
we won't see a key collision. In Fuchsia, as the key has to wait for the
Vulkan surface to render asynchronously, this suddenly becomes an issue.
This reverts commit 68d9ac44ec530a22beda85fcdf01871770a710d7.
https://github.com/flutter/engine/pull/7759 has landed without any
unexpected regressions. Hence we'll reland this as planned.
This decreases worst_frame_rasterizer_time_millis from 30ms to 10ms when
we enabled picture raster cache in tiles_scroll (i.e., lower the
threshold from 10 to 5).
After removing clips by default, the OpCount of a picture drops
significantly. That makes our old threshold suboptimal. The new
threshold reflects the clip change and will improve our scroll
performance by ~10% for complex_layout and flutter_gallery scroll
benchmarks:
(flutter_gallery) home_scroll_perf frame raster time:
average 9.1ms -> 7.4ms
90th_percentile 11.3ms -> 9.2ms
99th_percentile 45ms -> 38ms
complex_layout_scroll_perf frame raster time:
average 4.8 -> 4.4ms
90th_percentile 7.8ms -> 5.4ms
99th_percentile 19ms -> 17ms
This should also help mitigate issues like
https://github.com/flutter/flutter/issues/24782
Behavior (visual) changes should be very minor. Things that are to be expected:
* A few things were not color managed correctly by the transform canvas (color emoji, some color filters). Those will be handled correctly with the tagged surfaces (although we're always transforming to sRGB, so nothing should change until we target a wider gamut).
* Image filtering will happen in the source color space, rather than the destination. Very minor.
* The transform canvas did caching of images in the destination color space. Now, the conversion happens at draw time. If there are performance issues, images can be pre-converted to the destination with makeColorSpace().
When we visit a PlatformViewLayer during the paint traversal it replaces
the PaintContext's canvas with a new one that is painted ontop of the
embedded view.
We need to make sure that operations applied by parent layers are also
applied to the new canvas.
To achieve this we collect all the canvases in a SkNWayCanvas and use
this canvas by non leaf nodes. Leaf nodes still paint only to the "current"
canvas.
This PR moves the overlay canvas creation from the paint phase to the
preroll phase, collects them into a SkNWayCanvas and set it in
PaintContext.
To keep this PR focused, I only used the internal_nodes_canvas in the
tranform_layer.
Will followup with a PR that changes all internal layers to use the
internal_nodes_canvas.
The overlay surfaces are going to be the same IOSSurface implementation
with the platform views controller set to null (so these are surfaces
that don't support embedding platform views to them).
* Adds a FlutterOverlayView which is a UIView that's showing an
overlay surface.
* Creates an overlay surface for each embedded UIView (done in
FlutterPlatformViewsController).
* Changes CompositeEmbeddedView to return a new canvas.
* Makes the PlatformViewLayer replace the PaintContext's canvas with
the canvas for the overlay view.
* Changed canvas in PaintContext to be a pointer so it can be changed.
TBD in following PRs:
* Copy the current canvas state when replacing a canvas in PaintContext.
* Make FlutterOverlayView work with a GL backend (currently it only
works with software rendering)
Otherwise, this may trigger `FML_DCHECK(needs_painting())`. We haven't
caused crashes for our users because it probably requires a locally
debug engine build to trigger the assert.
For flow to manipulate the embedded UIViews during the paint traversal
it needs some hook in PaintContext.
This PR introduces a ViewEmbeder interface that is implemented by the
iOS PlatformViewsController and plumbs it into PaintContext.
The ViewEmbedder interface is mainly a place holder at this point, as
this PR is focused on just the plumbing.
* Revert "Revert "Allow raster caching any layer subtree (#6442)" (#6506)"
This reverts commit c6e6da512a54c1bb33a584b117bcf300ce71b166.
* Use raw pointer for RasterCacheKey
So we won't depend on whether it's a std::unique_ptr or std::shared_ptr.
We first test this with OpacityLayer. This test alone (without retained rendering) should have ~30% speedup as we'll have fewer render target switches by snapshoting in the Preroll instead of saveLayer in the Paint.
In my local flutter_gallery transition perf tests, the average frame time drops from ~16ms to ~12ms.
https://github.com/flutter/flutter/issues/21756
Although we do have a save before this SkAutoCanvasRestore so we
can theoretically send in doSave = false, it's safer to set doSave
to true to prevent future breakage.
As discussed with mtklein@google.com and reed@google.com, saving
canvas is very cheap in Skia so this should have no performance
impact. Skia is also considering remove doSave argument from
SkAutoCanvasRestore and always save the canvas.
