Videos and canvases have their own viz::Surface. This means that instead
of the cc::LayerTree emitting the viz::DrawQuad for the content, the
cc::LayerTree has a cc::SurfaceLayer, which emits a
viz::SurfaceDrawQuad, which refers to a viz::DrawQuad which is
submitted to a separate frame sink.
As a consequence of this architecture, the cc::Layer that knows the
cc::PaintFlags::FilterQuality and cc::PaintFlags::DynamicRangeLimit
is the cc::SurfaceLayer, which has no direct way to propagate those
parameters to the viz::TextureDrawQuad that will need to use them
(because that quad is submitted to the separate frame sink).
These cc::PaintFlags are propagated via various unreliable methods,
and as a result there are bugs (e.g, when they are changed on an
offscreen canvas, they have no effect until the canvas updates its
contents), and lots of complexity.
This architectural choice is one of many expedient hacks done to work
around the inefficiency of the cc::LayerTree implementation.
Add a mechanism whereby the cc::SurfaceLayer will be able to
propagate these parameters down to their child layers. To do this:
* For cc::PaintFlags::FilterQuality and DynamicRangeLimit, add new
mojom interfaces.
* To viz::SurfaceDrawQuad, add optional override_child_filter_quality
and override_child_dynamic_range_limit.
* In SurfaceAggregator::EmitSurfaceContent, propagate these parameters
from to viz::SurfaceAggregator::CopyQuadsToPass.
* In viz::SurfaceAggregator::CopyQuadsToPass, if these parameters are
present, use them to override viz::TextureDrawQuad::nearest_neighbor.
Add several tests for the new viz::SurfaceAggregator behavior, and for
the new mojo serialization.
This is not actually used anywhere except for several new unit tests.
The next patch will propagate this back through viz::SurfaceLayer to
blink.
This is incidental clean-up being done while implementing the
dynamic-range-limit CSS property.
Bug: 40277822, 380896841
Change-Id: I4f822849c31dffb45ffcb373aaee30331b879696
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049919
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389689}
cc/mojom provides the mojom typemaps for cc types. This directory is where
cc types that appear as part of mojo APIs should be placed. Structures that
are defined in C++ and have mojo based NativeEnum definitions will
require legacy Chrome IPC validators, see cc/ipc.
aebe9d1b30