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 c5df60b6a186467803e021ac4dfbb26f0cebb08b.
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 0ec9ea75fe7ff9e2121b06fe7d7c9d9751778c65.
* 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
This essentially reverts https://github.com/flutter/engine/pull/4197/
as no one is (or soon will be) implementing an alternative LayerBuilder.
Let's just put everything in SceneBuilder to reduce the YAGNI
(you aren't gonna need it) smell. This will also make retained rendering
API changes much easier.
Cache a SkSurface with previously drawn shapes so that we do not need to draw them again in future frames.
On Nexus 5X test device, old render time for just the overlay was 1.3ms-3.0ms and this version improves to 0.9ms-1.3ms running flutter gallery in profile mode.
