A previous version of this change also removed
system compositing of PhysicalShapeLayers on
Fuchsia. In this reland, keep using system
composting for PhysicalShapeLayers.
Co-authored-by: David Worsham <arbreng@gmail.com>
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
Test: Ran test programs on Fuchsia and dumped Scenic scene graph using
`fx shell cat /hub/c/scenic.cmx/*/out/debug/dump-scenes`
Inspected scene graph to confirm removal of ShapeNodes.
FL-284 #done
Scenic has now fully transitioned to clipping by adding lists
of planes to Nodes; the old approach of adding a ShapeNode
"part" is now a no-op, and is safe to remove.
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.
This does not actually import the runners into the engine. It only sets up the targets so they need no modifications are necessary when the migration is done. The engine has been verified to build in both buildroots.
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 is the first step in making Flutter aware of and responsive to Z
bound overflow. On its own this patch shouldn't result in any changes in
behavior. This will need to be followed up with a patch in Fuchsia's
Flutter runner to set the Z bounds after this lands, and another patch
in the engine actually implementing the desired overflow behavior.
This Z bound info is routed through the engine itself to make sure the
bounds in flow are truly consistent from the Fuchsia runner. However
these values should eventually be exposed to the framework as well.
Looks like someone added a new use of the method while I was waiting for flutter
to roll. nuking the last instance so i can move forward with deprecating and
removing it.
mikejurka
Kaushik Iska
David Worsham
liyuqian
cfontas
Chris Yang
Michael Klimushyn
Zachary Anderson
Dan Field
Chinmay Garde
freiling