New issue
Advanced search Search tips

Issue 754786 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Aug 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug

Blocking:
issue 751739



Sign in to add a comment

Add UMAs tracking # of layer promotions due to various causes

Project Member Reported by chrishtr@chromium.org, Aug 11 2017

Issue description

Important ones I can see:

1. Overlap (measures layer explosion)

2. Transform / opacity animation (see also related issue 754471)

3. Assumed overlap (can be due to animation or inline transform)

4. Overall # of indirectly composited cases.

I think the way to implement this is to, in
CompositingRequirementsUpdater::UpdateRecursive(), at the end when we are done
with all reasons for a PaintLayer, check the CompositingReasons() bitfield
for it against various conditions to see what the causes of promotion were, and increment
counters accordingly.

Then once CompositingRequirementsUpdater is done,
output UMA integers counting each aggregation of an interesting category.
Note that it's important to aggregate over all frames, so this should be done somewhere
at the top level in PaintLayerCompositor.
 
Project Member

Comment 1 by bugdroid1@chromium.org, Aug 23 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/038da8ef0172d6ef447750227d740639581fb6be

commit 038da8ef0172d6ef447750227d740639581fb6be
Author: Xida Chen <xidachen@chromium.org>
Date: Wed Aug 23 11:50:58 2017

Add UMA for number of layer promotions

In this CL, we add histogram to check number of layers that gets promoted
due to the following reasons:
1. Overlap
2. Transform / opacity animation
3. Assumed overlap
4. Indirectly composited

We aggregate the number of layers over all frames.

Bug:  754786 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ifd099c6b1f88aa110ae9068ce6238d8a91f9a342
Reviewed-on: https://chromium-review.googlesource.com/619172
Commit-Queue: Xida Chen <xidachen@chromium.org>
Reviewed-by: Steven Holte <holte@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#496660}
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/third_party/WebKit/Source/core/paint/compositing/CompositingRequirementsUpdater.cpp
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/third_party/WebKit/Source/core/paint/compositing/CompositingRequirementsUpdater.h
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/third_party/WebKit/Source/core/paint/compositing/PaintLayerCompositor.cpp
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/third_party/WebKit/Source/core/paint/compositing/PaintLayerCompositor.h
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/third_party/WebKit/Source/platform/graphics/CompositingReasons.h
[modify] https://crrev.com/038da8ef0172d6ef447750227d740639581fb6be/tools/metrics/histograms/histograms.xml

Cc: ajuma@chromium.org
In cases of overlap, we also want to keep track of the promotion for the layer below. Since the compositor may do further squashing, counts collected in blink may not be accurate. We do a bit of compositing reason plumbing already (cf GraphicsLayerDebugInfo). We could adjust that plumbing and collect stats in CalculateRenderPasses and do reporting there.

cc'd ajuma, with whom I discussed this recently.
Whoops, missed a word. That should have read "promotion _reason_ for the layer below".
The compositor doesn't do any squashing right now...
Status: Fixed (was: Assigned)

Sign in to add a comment