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 is part of a larger effort to expose the difference between GrDirectContext,
which runs on the GPU thread and can directly perform operations like uploading
textures, and GrRecordingContext, which can only queue up work to be delivered
to the GrDirectContext later.
This avoids the possible matrix mismatch between RasterCache::Get and
RasterCacheResult::draw. See
https://github.com/flutter/engine/pull/17790 for an example that tries
to fix an earlier mismatch.
RasterCacheResult::draw constructs the device target rectangle by
calling SkRect::roundOut, which rounds down the left/top coordinates
and rounds up the right/bottom coordinates. The rounding can produce
a device rect whose width and/or height differs from the cache result
image's width/height by one pixel.
This caused regression in several benchmarks, including:
animated_placeholder_perf. Regression tracked in
https://github.com/flutter/flutter/issues/51776.
This reverts commit 01a52b9947054f57398f2aaa2b59e7d501506580.
If Rasterization fails, i.e. image.is_valid() is false, the cache might try rasterizing the image again on the next frame. Not only is this wasteful put might also prevent other pictures to be cached within the current frame budget.
RasterCache::Get() methods were not updating the RasterCache::Entry
access_count and used_this_frame fields, as is done in
RasterCache::Prepare(). This can result in onscreen images being evicted
from the cache as new entries are created (e.g. as new elements scroll
onscreen).
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.
