Reverting this broke the flow tests for the performance overlay:
```
../../flutter/flow/layers/performance_overlay_layer_unittests.cc:70: Failure
Value of: golden_data != nullptr
Actual: false
Expected: true
```
This reverts commit 8427d73c8340c9e51492689ee66261a4a72cac9e.
* Revert "Revert "Add mock capability to PerformanceOverlayLayer (#7537)" (#7765)"
This reverts commit 693645e4645001ae460d5794fa6f5c7066677955.
* Add command line args for golden dir and font file
This reverts commit 68d9ac44ec530a22beda85fcdf01871770a710d7.
https://github.com/flutter/engine/pull/7759 has landed without any
unexpected regressions. Hence we'll reland this as planned.
Note: the SetTranslationRH function is temporary and part of the smooth
transition plan for Scenics handedness inversion. See SCN-1054 for details.
We will follow this will a change to migrate back off SetTranslationRH
Submit after https://fuchsia-review.googlesource.com/c/fuchsia/+/255056
lands in fuchsia.git
Uses SetClipPlanesCmd in addition to the old clipping approach.
Flutter will use both clipping methods during a transition period
(Scenic will select internally which one to use).
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
This will further guard that the framework won't forget to set the
clip behavior.
This has been tested with the flutter/flutter framework
`flutter test --local-engine=host_debug_unopt`
to ensure a successful engine roll.
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().
Since it's adding to paint_layers_, I think the "painted" is a typo of
"paint". It's also a misleading typo which mistakenly let people believe
that the layer has already been painted.
This PR replaces the unused `PrerollContext::child_paint_bounds` with `PrerollContext::cull_rect` so we can prune unnecessary preroll tasks (especially cache) based on clips. This PR fixes https://github.com/flutter/flutter/issues/24712
Performance test has been added (https://github.com/flutter/flutter/pull/25381) to make sure that we won't regress again in the future.
Note that the cull_rect here is very similar to those removed in https://github.com/flutter/engine/pull/6352 . We can't compute cull rects in SceneBuilder because of retained layers. But we can still compute and use them to optimize performance in Preroll.
Right now we do it whenever the platform views preview flag is on.
This is less efficient, filed
https://github.com/flutter/flutter/issues/24133 to only do this when
there's a platform view in the tree.
Moved the frame buffer specific logic from IOSGLContext to IOSGLRenderTarget.
use recording canvases for overlays
Support platform view overlays with gl rendering.
This also changes the overlay canvases (for both software and gl
rendering) be recording canvases, and only rasterize them after
finishing the paint traversal.
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.
When the flag is true, we currently use a single thread configuration,
and disabled the raster cache for opacity layers.
The flag's name is 'io.flutter_embedded_views_preview'.
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.
This reverts commit 74662ab695238af0e7402f41c4bf9ad862bd37d2.
This should land after https://github.com/flutter/engine/pull/6442
* Add pragma vm:entry-point
Otherwise, an object may be both null and an instance of EnginieLayer at
the same time in Dart.
* 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
To make the PR minimal, we currently only share the engine layer when `pushPhysicalShape` (for Fuchsia) or `pushOffset` (for `RepaintBoundary` and `Opacity`) are called. They should be sufficient for our short-term perf goal. In the future, we can incrementally share more engine layers with the framework.
https://github.com/flutter/flutter/issues/21756
