Sometimes when using the find in page feature, scrollbars will flicker
for a frame and then go back to normal. Please see the video in the
linked bug.
To repro somewhat consistently (easier to do in local builds):
1. Open a webpage with text.
2. While the page is still loading content, or the main thread is busy,
use Ctrl+F and find some text.
3. You'll sometimes see the flicker shown in the video.
I've used this page repro: https://jsfiddle.net/nxd230st/
You might need to save the page into a local file to be able to see
the problem.
Root cause:
Scrollbars knowing they have tickmarks present and the paint
invalidation that happens from tickmarks appearing does not necessarily
happen in sync. It can happen that Scrollbar::HasTickmarks() returns
`true` *before* LayoutBox::InvalidatePaintForTickmarks() is called.
If this happens, the layer code will stop scaling scrollbars as 9patch
and present them as if the bitmap was the size of the scrollbar, which
causes the image to be stretched out (as seen on the video). Once the
paint invalidation happens, the scrollbars are re-painted to a bitmap
of an appropriate size and things go back to normal. Usually, this
desynchronization doesn't happen.
Fix:
9 patch scrollbars now re-paint scrollbars when the tickmark status
changes on the scrollbar, that way the values will never be internally
incoherent and we won't see the incorrect stretching of the smaller
bitmap.
Bug: 383174953
Change-Id: I916bff38f8d0b20fa86faf3dc9981fad68ee48ee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6086899
Reviewed-by: Yaroslav Shalivskyy <yshalivskyy@microsoft.com>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1396001}
This CL adds a feature to allow decoupling BeginImplFrame() from
BeginMainFrame(). It works by not sending a BeginMainFrame() (but not
marking it as sent either) in the scheduler, on high refresh rate
clients.
Concretely, when the feature is enabled, no more than one BeginMainFrame
is sent per 1/60th of a second, which in practice means that impl-side
scrolling (even when blocked on main, i.e. with a non-passive observer)
and CSS animations work at 120fps, but main updates
(i.e. requestAnimationFrame()) happen at 60fps.
This patch works, but is not 100% complete, hence the feature is
disabled, though exercized with unit tests.
Change-Id: Iab0b0aad76ee4437b4ed7a39137fd88b1b5b8a7e
Bug: 379678455
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6054335
Commit-Queue: Benoit Lize <lizeb@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1395984}
A step toward getting cc_unittests to pass with VizLayers enabled. In
particular, this change gets the TileManager unittests to pass. We will
of course fill in FakeLayerContext as tests show need.
Bug: 383270106
Change-Id: I1ddba6df9aa44159730799804df0281c700fa306
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6089707
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1395443}
Fix the CC position by correcting the transform matrix delta y for
feature DynamicSafeAreaInsetsSupportedByCC when
DynamicSafeAreaInsetsOnScroll on.
(Thanks to skobes@ for the fix on calculating SAIB.)
Bug: 373980016
Change-Id: Id5321adc526311cfe4bc8fa2847b6ccfa4c58f32
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6085305
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1395041}
The dbg bot was failing due to excessive amount of logs during
GPU restart. This CL reduces the amount of log by
1) Using GpuChannelHost::CrashGpuProcessForTestin to doesn't print
stack trace.
2) Not logging if CreateGpuMemoryBuffer fails when the gpu channel
is not connected.
This CL also removes the dependecny to chrome/browser in the test,
Bug: 368538284
Change-Id: I3c43d68036f067a48dc14f8d08a8ee9abb51f007
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6072549
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1394576}
(1) Add new composition flags for supporting SAI in CC.
CompositingReason::kAffectedBySafeAreaBottom
compositor_node.moved_by_safe_area_bottom
transform_tree.nodes_affected_by_safe_area_inset_bottom
These flags are set according to
ComputedStyle::IsBottomRelativeToSafeAreaInset() in Blink.
(2) Plumb |moved_by_safe_area_bottom| and |nodes_affected_by_safe_area_inset_bottom| from Blink to CC.
(3) Calculate and apply the transform y adjustment in CC.
This new feature is put behind the feature flag DynamicSafeAreaInsetsSupportedByCC, and it's disabled by default.
Bug:373980016
Change-Id: I6f9bcd09020b3f1c65246cb4567fa82884a47d0d
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6066002
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1394502}
This is a reland of commit 37855993b8
Added fuzziness to
tests and will queue bots for the broken test.
The issue that caused bots to fail is something unrelated to 9-patch
scaling, for some reason there are some shades of gray different
at the bottom of the scrollbars:
https://ci.chromium.org/ui/p/chromium/builders/ci/mac-skia-alt-arm64-rel-tests/5909/test-results?sortby=&groupby=
Original change's description:
> Fix scaling for 9-patch scrollbars.
>
> When pinch-zooming in a subscroller that is being rendered with nine-
> patch scrolling the track shows strange behavior. In official builds
> the rendering of the thumb and arrows gets distorted and in local
> builds it is clear that the scrollbar's track and buttons are not
> being scaled.
>
> The root causes for this bug were:
> 1. The patch generator was not being passed the scaled rect by the layer
> code, it was only being given the layer's dimensions.
> 2. The track's bitmap wasn't being repainted when scaled, which in the
> best case scenario caused the arrows to look blurry, and in the worst
> it caused the rendering to be completely wrong.
> 3. The aperture wasn't being scaled to consider the bitmap's scaled
> dimensions, which caused scaled scrollbars to be rendered
> incorrectly.
>
> This CL:
> 1. Adds a new condition for the scrollbars to be re-painted whenever the
> layer's internal scale changes.
> 2. Refactors the ScrollbarTheme 9patch-Canvas and 9patch-Aperture code
> to consider the scale of the layer and return the correct sized
> values.
> 3. Adds web and unittests to cover the new behavior.
>
> Bug: 378027651
> Change-Id: Ie467ecc8139e2a6b03d5d073ac2c860bf2cd571d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013524
> Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com>
> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
> Reviewed-by: Yaroslav Shalivskyy <yshalivskyy@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1385971}
Bug: 378027651
Change-Id: I57eb380aeb84596083c6db966d7b71eb10d20f68
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6081995
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1394355}
This CL adds a Blink use counter that gets fired when a web page has an
element whose computed style for the touch-action css attribute would
disable handwriting for the element if the handwriting keyword were
implemented.
Handwriting would be disabled when touch-action is specified with any
keyword other than `auto` or `manipulation`. The use counter will be
fired when any other keyword[1] is specified, excepting when
touch-action is declared with the `none` keyword in which case
handwriting would be disabled but that would be by design.
For more context on the cause of this use counter, please see the linked
bug.
[1] https://w3c.github.io/pointerevents/#dfn-touch-action-values
Bug: 378027646
Change-Id: I88e9c1641490382cc8477cb59e97ae671c680ea9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6005047
Reviewed-by: Adam Ettenberger <Adam.Ettenberger@microsoft.com>
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1393914}
This reverts commit 37855993b8.
Reason for revert: Consistent mac-skia-alt-arm64-rel-tests failures after this CL: https://ci.chromium.org/ui/p/chromium/builders/luci.chromium.ci/mac-skia-alt-arm64-rel-tests?limit=1500
First failure: https://ci.chromium.org/ui/p/chromium/builders/ci/mac-skia-alt-arm64-rel-tests/5143/blamelist
Original change's description:
> Fix scaling for 9-patch scrollbars.
>
> When pinch-zooming in a subscroller that is being rendered with nine-
> patch scrolling the track shows strange behavior. In official builds
> the rendering of the thumb and arrows gets distorted and in local
> builds it is clear that the scrollbar's track and buttons are not
> being scaled.
>
> The root causes for this bug were:
> 1. The patch generator was not being passed the scaled rect by the layer
> code, it was only being given the layer's dimensions.
> 2. The track's bitmap wasn't being repainted when scaled, which in the
> best case scenario caused the arrows to look blurry, and in the worst
> it caused the rendering to be completely wrong.
> 3. The aperture wasn't being scaled to consider the bitmap's scaled
> dimensions, which caused scaled scrollbars to be rendered
> incorrectly.
>
> This CL:
> 1. Adds a new condition for the scrollbars to be re-painted whenever the
> layer's internal scale changes.
> 2. Refactors the ScrollbarTheme 9patch-Canvas and 9patch-Aperture code
> to consider the scale of the layer and return the correct sized
> values.
> 3. Adds web and unittests to cover the new behavior.
>
> Bug: 378027651
> Change-Id: Ie467ecc8139e2a6b03d5d073ac2c860bf2cd571d
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6013524
> Commit-Queue: Gaston Rodriguez <gastonr@microsoft.com>
> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
> Reviewed-by: Yaroslav Shalivskyy <yshalivskyy@microsoft.com>
> Cr-Commit-Position: refs/heads/main@{#1385971}
Bug: 378027651
Change-Id: I2366ec186c5be88ed7580ae526f93cd3d3a6c9e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6079956
Owners-Override: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Fahad Mansoor <fahadmansoor@google.com>
Auto-Submit: Sergey Poromov <poromov@chromium.org>
Commit-Queue: Fahad Mansoor <fahadmansoor@google.com>
Cr-Commit-Position: refs/heads/main@{#1393595}
This reverts commit f412079bd8.
Reason for revert: This patch fixes the 1% regression on Mac and causes the 6% regression on Windows, so it's better to use DrawOval instead of drawPath.
Original change's description:
> Fix performance regression on ChartJS
>
> Using drawArc instead of drawOval for closed circle to improve
> performance on ChartJS.
>
> Bug: 371233772
>
> Change-Id: Ie5eb75342ec85e2fbeb5ab3ecae2212a504ae02a
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5962321
> Reviewed-by: Florin Malita <fmalita@chromium.org>
> Commit-Queue: Yi Xu <yiyix@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1381356}
Bug: 371233772
Change-Id: I1b993d6b80bb2429a5289536bf4e478243cb0d37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6077785
Commit-Queue: Yi Xu <yiyix@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1393472}
This CL adds new tracing events that correspond to the following Mojo
messages being sent:
* blink.mojom.WidgetInputHandler::DispatchEvent from the browser main
thread to a renderer's compositor
* viz.mojom.BeginFrameObserver::OnStandaloneBeginFrame from Viz to the
browser main thread (for flings)
* viz.mojom.CompositorFrameSinkClient::OnBeginFrame from Viz to a
renderer's compositor
* viz.mojom.CompositorFrameSink::SubmitCompositorFrame from a renderer's
compositor to Viz
PERFETTO_TESTS=`autoninja -C out/Default perfetto_diff_tests && out/Default/bin/run_perfetto_diff_tests`
Bug: 374100154
Change-Id: Iecddea6e7cb65f30026dc7a85f8c4d81ffd687b0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049015
Reviewed-by: Oksana Zhuravlova <oksamyt@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Commit-Queue: Petr Cermak <petrcermak@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1393202}
Rename SharedImageUsage SHARED_IMAGE_USAGE_CPU_WRITE to
SHARED_IMAGE_USAGE_CPU_WRITE_ONLY in order to clarify the intent that
this usage is only meant for write only and not read.
This was required as all the other WRITE usages we have also implies
READ as well.
This CL is a no-op and strictly just a rename.
Bug: 40264379
Change-Id: I7e7a4e5102ad422d1b73b9cf02751c6944cfa12e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6071632
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Kramer Ge <fangzhoug@chromium.org>
Commit-Queue: vikas soni <vikassoni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1393191}
When the metal::HDRCopierLayer is performing its own tone mapping it
needs to re-draw every time that the HDR headroom changes. To ensure
this happens
- make cc::SurfaceLayer::RequiresSetNeedsDisplayOnHdrHeadroomChange
return true (because it may be the cc::LayerTree representation of
the content)
- ensure LayerTreeHost::SetDisplayColorSpaces calls SetNeedsCommit
- make -[HDRCopierLayer setHDRContents] re-draw when the HDR headroom
changes (but only if it is down its own tone mapping)
While in the area, fix the tone mapping math to clamp the gain weight
to [0, 1].
Bug: 343249142
Change-Id: Ic8e6151ceca8e8342df30d2a381e368c57fe329e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6074481
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1393130}
Checking `std::is_trivially_copyable_v<>` on the element type is not
sufficient; that may leave padding bytes we don't want to serialize.
Always using per-element writing avoids span having to discern whether
this might be a safe usage of those intervening padding bytes.
Also adjusts the touched APIs to use refs instead of pointers to comply
with the current style guide and be more obviously non-null-expecting.
Bug: 382041497
Change-Id: I286dcfff63e99d42a3e2e7f3e29961d083af28dd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6075415
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Peter Kasting <pkasting@chromium.org>
Auto-Submit: Peter Kasting <pkasting@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1393120}
Propagate cc::LayerImpl's DynamicRangeLimit to viz::TextureDrawQuad.
Propagate viz::TextureDrawQuad's DynamicRangeLimit over mojo.
In surface aggregator, overwrite viz::TextureDrawQuad's
DynamicRangeLimit if the viz::TextureDrawQuad comes from a
cc::SurfaceLayer that has override flags set.
In viz::SkiaRenderer::GetColorSpaceConversionFilter, use the
DynamicRangeLimit to limit the headroom for drawing.
Move the computation of effective HDR headroom out from the static
helper ComputeHdrHeadroom in PaintOpReader to a member function on
cc::PaintFlags::DynamicRangeLimitMixture.
Bug: 40277822
Change-Id: If64b045f76b24ff9e7dc2b89cc426891c84101f3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068767
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1392812}
Previously we regenerated discardable image map on raster-inducing
scroll, but a removed paint worklet (scrolled out of view) might be
still running, and OnPaintWorkletResultsReady() for the worklet
would find inconsistent data structure which caused crash.
Now let the discardable image map not depend on scroll offset. We
collect all images under a DrawScrollingContentsOp, and use the
rect of the op as the image rects. The result is basically the same
as that of composited scrollers. This reduce the amount of work
on scroll, and make the logic simpler and less error-prone.
Bug: 379297064
Change-Id: Idf3384da4a0cf1c20994a47cc055ba41e9c28d31
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6067991
Commit-Queue: Philip Rogers <pdr@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1392574}
(1) Scale max_safe_area_insets by the device scale factor in Blink
and pass this scaled insets to CC.
(2) Change the max_safe_area_insets to the float type gfx::InsetsF
(3) In CC, store |max_safe_area_insets| in LayerTreeImpl (the pending
tree and the active tree). It's no longer stored in
LayerTreeHostImpl since |max_safe_area_insets| could change after a new device scale factor .
Bug: 373980016
Change-Id: I05dabead96c9748c130019b51cb0b8cc748e719e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6068811
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1392466}
Split 8/8 from:
https://chromium-review.googlesource.com/c/chromium/src/+/6055399
This patch addresses inconsistencies in array initialization where the
declared array size does not match the number of elements provided in
the initializer list. This can lead to confusion and potential errors,
as the remaining elements are implicitly initialized to zero. For
example, initializing with = {2} might mislead developers into thinking
the entire array is filled with 2s, when in fact only the first element
is assigned that value.
https://godbolt.org/z/4sbd9nreT
The changes ensure that:
- Array sizes accurately reflect the number of elements being explicitly
initialized.
- Zero-initialization is explicitly expressed using {} when intended.
This improves code clarity and maintainability by making the
initialization intent clear and consistent.
This change also aims to allow the std::array rewriter to "crash" when
encountering a mismatching size where it would be difficult to rewrite.
Not having any occurrences of this pattern in the codebase will avoid the issue.
Bug: 356643982
Change-Id: Ie2df5a02a5a2e96a117b5ae4bc86df2b031da972
AX-Relnotes: n/a.
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6063246
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1391754}
The canvas has not been used since crrev.com/1289572 (M126), which was
a mistake, but we haven't found any bug since then. The differences
between the original canvas and this canvas are
1. The original canvas has clips from previous paint ops;
2. The original canvas has transforms from previous paint ops, while
this canvas only has the scale components.
We won't use the previous clips and transforms to map op_rect [1].
The ctm will be passed to DrawImage which affects:
- DrawImage::matrix_is_decomposable(), which can be different with the
different canvases, but it doesn't look incorrect to determine the
filter quality based on the total ctm instead of the ctm under the
shader.
- DrawImage::scale(), which should be the same.
[1] https://source.chromium.org/chromium/chromium/src/+/main:cc/paint/discardable_image_map.cc;drc=0eb474d6793456826037bf33212ccba9da236402;l=102
Change-Id: I9dbfc88b9ee02771b5884f1cdcfc092b188aa41b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6065362
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1391068}
Add a parameter on cc::SurfaceLayer to cause the viz::SurfaceDrawQuad::
override_child_filter_quality and override_child_dynamic_range_limit
properties to be set.
The next change will call this in blink::SurfaceLayerBridge.
This is incidental clean-up being done while implementing the
dynamic-range-limit CSS property.
Bug: 40277822, 380896841
Change-Id: I48c02d80f5281382f0927681608c2ad2630df039
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6049749
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389719}
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}
Trunk Clang now warns on constructors when -Wunsafe-buffer-usage is
turned on. Temporarily adding allow_unsafe_buffers pragma in few files
so they can be compiled to trunk clang. Once the clang changes are
rolled in (crbug.com/375635728), the code owners should consider
removing the pragma and fixing those warning instances.
Bug: 377326291
Change-Id: I07fe41cd86af29501c07cc20ecd790a85c760f15
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6054357
Reviewed-by: Nico Weber <thakis@chromium.org>
Owners-Override: Nico Weber <thakis@chromium.org>
Commit-Queue: Hans Wennborg <hans@chromium.org>
Auto-Submit: Hans Wennborg <hans@chromium.org>
Commit-Queue: Nico Weber <thakis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1389412}
There are exactly four use-cases that create layer with flipped = true:
* DrawingBuffer, flip depends on composition and MESA_framebuffer_flip
* ImageLayerBridge: This used to update flip for each resource
* PepperPluginInstanceImpl for Graphics3D case. This is the only case
which uses SetTransferableResource instead of TextureClient
* TestPlugin: Always uses bottom-left.
This CL makes TransferableResource adjustment right the place where
we pass it to TextureLayer, to make sure it's no-op.
Follow-up will push them closer to place where we create the resource.
This allows to remove flip from TextureLayer entirely.
Bug: 378688985
Change-Id: Ide4b81711db84ecb469bf3ee3731ec3e055489fd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6039385
Reviewed-by: Mike West <mkwst@chromium.org>
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1388225}
TextureLayer was flipped by default, but most production use-cases
would call SetFlipped right after that. This CL adds param to ctor to
avoid default value.
It also updates all unit tests that don't care about flipped to pass
false.
Bug: 378688985
Change-Id: I33235d0970bc023155ae9bb70c591c7f4239aa0b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6039088
Reviewed-by: Kyle Charbonneau <kylechar@chromium.org>
Commit-Queue: Vasiliy Telezhnikov <vasilyt@chromium.org>
Reviewed-by: Derek Schuff <dschuff@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1388200}
kMediaSharedBitmapToSharedImage has been enabled by default since M124
SharedBitmapReporter and SharedBitmapId are removed from
SoftwarePlaneResource. They are no longer used after converting media
SharedBitmap to SharedImage.
Bug: 40064122
Change-Id: Id22fd38bf2a48cba2fced33082ad0a29cd683983
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6044504
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Vasiliy Telezhnikov <vasilyt@chromium.org>
Commit-Queue: Maggie Chen <magchen@chromium.org>
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1388006}
The CSS image-rendering property determines the cc::FilterQuality
to use when rendering an image. When blink renders an image, it
stores the cc::FilterQuality in blink::ScopedImageRenderingSettings
(this structure also includes DyanmicRangeLimit -- more on that later).
When viz renders an image or a canvas, this property is set on the
cc::TextureLayer. But not quite. We actually just set a boolean
for "nearest neighbor". This property is already present on
NinePatchLayer and TextureLayer, but will also be needed for
VideoLayer and SurfaceLayer.
Remove the various sub-class booleans and replace them with a
member in the base class' cc::Layer::RareInputs. Plumb the
DynamicRangeLimitMixture through the same path.
Ensure that both of these properties cause a commit when changed
(and add tests for this).
Bug: 40277822
Change-Id: I4b702ce52e210e6ebd78e22d3425d8b728f5df6c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6000365
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Reviewed-by: Fernando Serboncini <fserb@chromium.org>
Commit-Queue: ccameron chromium <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1387523}
ThroughputTracker can track any compositor metrics over a sequence of
time. It current name reflect its usage to collect smoothness related
metrics. However, we want to use mechanism to track other metrics
(paint) as well. The naming convention should reflect this
genericness.
In crrev.com/c/6040362, we did renaming in ui/compositor and ash/
directories. In this CL, we are renaming cc/ and blink/ directories. (mostly)
Bug: b:380318532
Change-Id: I71e60a3312d30224b77fa51dbf04ebbc55837f3a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6042895
Commit-Queue: Zoraiz Naeem <zoraiznaeem@chromium.org>
Reviewed-by: Stefan Zager <szager@chromium.org>
Reviewed-by: Jonathan Ross <jonross@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1387187}
