Another pro:

c. Increases developer control. Right now, developers cannot turn off accelerated
overflow scroll. (However, they can turn it on with a single line of CSS.)

I wonder if we could make the scrollers raster inducing in this case. If you did that, I think you'd only be paying the memory cost for the recording (SkP stuff) beyond the scroll clip, but you'd still be accelerated. I think xidachen and flackr have been working toward this and it might be a good middle ground in the memory/perf tradeoff. Perhaps this could be a configuration in the finch experiment?

That would be possible, but more work. Turning off the accelerated overflow
trigger is really easy, as there is already a flag for it.

Re #3, yes, I think that's strictly superior as it doesn't have the memory cost but still avoids the performance bottleneck of hitting the main thread for scrolls. We will be working on this and it should be a strict win to replace any fallback non composited logic we add.

This experiment sounds very similar to Yi's experiment (issue 684631). Yi, do you have some data collected about how often android users scroll the main scroller vs these other (smaller) ones?

According to UMA stats, it appears that 5% of scrolls on Android are
for non-root scrollers. For low-end Android devices, the rate appears to be 2.5%.

I got this by adding Event.Scroll.ScrollerSize.OnScroll_Touch to Event.Scroll.ScrollerSize.OnScroll_Wheel
and dividing by Renderer4.MainThreadGestureScrollReason.

Regarding issue 684631: it appears from the commits on the bug that the work done
so far was to add metrics (which were quite useful - see above). Is that correct?

According to the current metrics in beta, roughly 90% scrollers on Android devices are smaller than 200000 pixels (400 * 500) and 40% of them get scrolled by users. So turning off the flag for all non-root scrollers may have too much impact.

If we look at 70000 pixels, roughly 60% scrollers are smaller than that and only 10% get scrolled. So maybe we should turn off the acceleration for certain scrollers that are smaller than some threshold? My current work is about finding a reasonable threshold that could affect less user scrolls but have more memory save.

If we don't composite smaller scrollers we will definitely save memory. The question is that how much memory we could save. Currently, we allocate ~4.94MB memory for a root layer of size 1440 * 900 and ~1.15MB for that of size 412 * 732. With a threshold 50000px, we allocate ~0.2MB for the "largest" small scroller and 0.07MB~0.1MB for most of other small scrollers. As a result, we may be expecting possible up to 17% "tile" memory save. My concern is that in cases that we have a large screen(root layer) and several small scrollers, we may expect <1% memory save. In that case, would people argue that the improvement is neglectable? e.g. we've already allocated ~8MB for non-small scrollers, we can afford another 0.08MB for small scrollers so we won't have performance loss.

Any thoughts?

Re #6, there is another metric Event.Scroll.ScrollerSize.OnLoad to show the size distribution on page load. The upcoming work includes adding metrics that records memory save, launch a finch trial that shows the differences w, w/o compositing the small scrollers.

I think we should pursue the raster-inducing scroll approach, but not the quick fix main-thread scrolling approach.  In my opinion, if we gain on the order of 10MB of RAM on a 1GB device at the cost of main-thread scrolling on an element the user wants to interact with, that's a bad tradeoff that decreases our Pareto efficiency, whereas if we gain the same amount of RAM at the cost of only extra raster, that's a reasonable tradeoff.

We proudly shipped universal accelerated scrolling circa 2012, when high-end devices like the Galaxy Nexus had 1GB of RAM just like low-end devices today.  At that time, main-thread scrolling cases were routinely filed as serious jank bugs that users often perceived as making pages practically unusable.  I don't want to go back to triaging these bugs.  Here's an example of a recent P1 bug caused by an accidental triggering of main-thread scrolling:  http://crbug.com/701355 

Also, input-team's long-term plan is to delete main-thread scrolling codepaths entirely: see https://docs.google.com/document/d/1op5USoxDnN6yxB8EiFHYcGHacrZZRVKVqu4mSXFd6Ns/edit .  This means that allowing web developers to control this is an anti-goal.

For those who are not familiar with the bug mentioned in #9:
The bug was caused by incorrect propagation of main thread scrolling reasons. It resulted in an unfortunate janky effect that "any" scroll on that reddit page after login was handled on main thread. This experiment and mine are not expected to cause perf issue like that.

Based on the metrics, almost 50% scrollers on android device are smaller than 30000px, roughly 160 * 160. While we compositing most of them, only 2% get scrolled by users and among the 2% some scrollings have been handled by main thread already due to certain main thread scrolling reasons. It means less than 2% (we don't know whether it's 0.5%, 1.5% or 1.9% for sure) would be affected by not compositing scrollers that are smaller than 30000px. That's why I'm trying to launch a finch trial to see the difference.

I agree that raster-inducing scroll will be the cure here but it looks like a long-term plan. It would be great if we can achieve something without jeopardizing the performance (too much).

The devices we are most concerned with  right now are 512MB, not a 1GB device. I'm happy to update the
plan to target 512MB only.

10MB savings on that is a really big deal, especially considering that both Chrome and Android have bloated
their memory requirements significantly since 2012. Reducing that by 10MB is, according to the urgency
attached to current efforts, more important than the other costs you mention.

Regarding developer control: no, it's not a general goal to allow control of it, but memory constraints require
us to compromise and coordinate with developers of leading-edge PWAs to optimize performance. The plan outlined
in this bug does not preclude any change in the future, and does not add any new APIs.

Finally, raster-inducing composited scroll is not implemented and won't be for some time. Something is likely needed in the meantime.

Re finch for small scrollers: was one implemented?

OK, I'm more comfortable with it if it only targets 512MB, thanks.  I agree the tradeoff is different there.

Great. Thanks for your feedback, it's very useful.

Pending CL: https://chromium-review.googlesource.com/c/576607/

Chris, I don't understand why raster inducing scrollers are difficult, at least from the paint side.

Please let me know if I'm missing something, but this seems like a cc-internal optimization of how we raster, with no impact on SPv2, or on the compositing artifacts sent to cc (prop trees, layers, etc).

If that's true, is there any issue with trying the optimization and then evaluating it as well in the finch trial?

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

commit c3de4bd44dcfed3706d8b4aeac967002d3ca9a16
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Wed Jul 19 20:30:03 2017

Add a content feature to turn off prefer-compositing-to-lcd-text,
for low-end Android devices.

TBR=piman@chromium.org

Bug:  746018 
Change-Id: I40f0dbddd1efc8a751fc3d48c97446e1f04bbeeb
Reviewed-on: https://chromium-review.googlesource.com/576607
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#487958}
[modify] https://crrev.com/c3de4bd44dcfed3706d8b4aeac967002d3ca9a16/content/public/common/content_features.cc
[modify] https://crrev.com/c3de4bd44dcfed3706d8b4aeac967002d3ca9a16/content/public/common/content_features.h
[modify] https://crrev.com/c3de4bd44dcfed3706d8b4aeac967002d3ca9a16/content/renderer/render_view_impl.cc

Yi also added a flag - SkipCompositingSmallScrollers - which should help us to not composite things like textareas while still compositing large overflow scrollers which may be serving the purpose of the application scroller (i.e. gmail). Chris, what do you think about adding this to the experiment? We can measure the tradeoff of memory vs important latency metrics - I think this may be a better tradeoff (still compositing scrolls on large scrollable regions) and get us most of the memory savings (not compositing textareas and other smaller overflow / UI components).

I also have a patch that uses the flag. https://chromium-review.googlesource.com/c/585290/

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

commit f470dd6dfd2e88e40e344e5bd914c90c999ddbe4
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Tue Jul 25 19:09:59 2017

Don't accelerate scrolling for <input> or <select> elements.

The only advantage to doing so is to provide jank-free touch
gesture scrolling. However, almost all interaction use-cases for
<input> are non-scrolling: typing, clicking, etc., all of which
require the main thread.

Also, while almost all <input> element composited layers are small,
they can cause layer explosion due to transitive effects on other
content.

Bug:  746018 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Iba68bdf5ec37aa1afd5596318b438f4536663bd6
Reviewed-on: https://chromium-review.googlesource.com/578717
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#489395}
[add] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/compositing/dont-composite-select-elements.html
[add] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/compositing/dont-composite-text-input-elements.html
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/linux/paint/invalidation/invalidate-caret-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/linux/paint/invalidation/selection/selection-in-composited-scrolling-container-expected.txt
[delete] https://crrev.com/16a090e32e086668f52fec09b28239e01d2d9f8d/third_party/WebKit/LayoutTests/platform/mac-mac10.10/paint/invalidation/invalidate-caret-in-composited-scrolling-container-expected.txt
[delete] https://crrev.com/16a090e32e086668f52fec09b28239e01d2d9f8d/third_party/WebKit/LayoutTests/platform/mac-mac10.10/paint/invalidation/selection/selection-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/mac-mac10.9/paint/invalidation/invalidate-caret-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/mac-mac10.9/paint/invalidation/selection/selection-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/mac/paint/invalidation/invalidate-caret-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/mac/paint/invalidation/selection/selection-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/win/paint/invalidation/invalidate-caret-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/LayoutTests/platform/win/paint/invalidation/selection/selection-in-composited-scrolling-container-expected.txt
[modify] https://crrev.com/f470dd6dfd2e88e40e344e5bd914c90c999ddbe4/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp

Re comment 16: restricting to small scrollers sounds like a useful variant of the
experiment to run, I agree. We can also do it on more than just low-end Android
devices.

How about we run the existing code in an experiment for a couple of weeks and then
review the results? There are 6 weeks until the next branch point, so we can run
more than one experiment.

Pending CL regarding not compositing small scrollers: https://chromium-review.googlesource.com/c/585290/

Early findings on issue 748693:

1. Significant decrease in crash rate and GPU memory
2. No significant impact on number of total cc::Layers or cc::PictureLayers.

Also, Eric happened across a site already that performs abysmally with this feature
on (Times of India), which apparently uses a non-root scroller. yigu@'s approach will
fix this.

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

commit db51f647779cce657c1724d27e0d863c87d9c1bf
Author: Yi Gu <yigu@chromium.org>
Date: Tue Aug 01 06:01:02 2017

Experiment on not compositing small scrollers

This patch is to avoid compositing scrollers smaller than 160000px to
save memory. On Android devices ~90% scrollers are smaller than this
threshold so we could expect a lot of memory save by not compositing
them. Meanwhile ~70% scrollers that users actually scroll are greater
than this threshold which means that at least 70% scrolls won't be
affected by this experiment.

Note: for small scrollers with separate compositing reasons, e.g.
"will-change: transform;", they should be composited anyway.

Bug: 684631,  746018 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I354ce936e981e66bcbc59f7248474cd29a9ecf8c
Reviewed-on: https://chromium-review.googlesource.com/585290
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490869}
[modify] https://crrev.com/db51f647779cce657c1724d27e0d863c87d9c1bf/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp
[modify] https://crrev.com/db51f647779cce657c1724d27e0d863c87d9c1bf/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/db51f647779cce657c1724d27e0d863c87d9c1bf/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h
[modify] https://crrev.com/db51f647779cce657c1724d27e0d863c87d9c1bf/third_party/WebKit/Source/core/paint/PaintLayerScrollableAreaTest.cpp
[modify] https://crrev.com/db51f647779cce657c1724d27e0d863c87d9c1bf/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

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

commit b5e3fb4ddb04d28f70be4aa455ab60a6b643b913
Author: Jan Krcal <jkrcal@chromium.org>
Date: Tue Aug 01 08:24:19 2017

Revert "Experiment on not compositing small scrollers"

This reverts commit db51f647779cce657c1724d27e0d863c87d9c1bf.

Reason for revert: This CL seem to break Android bots https://uberchromegw.corp.google.com/i/chromium.webkit/builders/WebKit%20Android%20%28Nexus4%29

The output log:

C  192.874s Main  [FAIL] PaintLayerScrollableAreaTest.SelectElementPromotionTest:
C  192.874s Main  [ RUN      ] PaintLayerScrollableAreaTest.SelectElementPromotionTest
C  192.874s Main  [INFO:SkFontMgr_android_parser.cpp(609)] [SkFontMgr Android Parser] '/system/etc/fonts.xml' could not be opened
C  192.874s Main  
C  192.874s Main  [INFO:SkFontMgr_android_parser.cpp(609)] [SkFontMgr Android Parser] '/vendor/etc/fallback_fonts.xml' could not be opened
C  192.874s Main  
C  192.874s Main  ../../third_party/WebKit/Source/core/paint/PaintLayerScrollableAreaTest.cpp:607: Failure
C  192.874s Main  Value of: paint_layer
C  192.875s Main    Actual: false
C  192.875s Main  Expected: true
C  192.875s Main  [  FAILED  ] PaintLayerScrollableAreaTest.SelectElementPromotionTest (83 ms)
C  192.875s Main  [----------] 1 test from PaintLayerScrollableAreaTest (83 ms total)

Original change's description:
> Experiment on not compositing small scrollers
> 
> This patch is to avoid compositing scrollers smaller than 160000px to
> save memory. On Android devices ~90% scrollers are smaller than this
> threshold so we could expect a lot of memory save by not compositing
> them. Meanwhile ~70% scrollers that users actually scroll are greater
> than this threshold which means that at least 70% scrolls won't be
> affected by this experiment.
> 
> Note: for small scrollers with separate compositing reasons, e.g.
> "will-change: transform;", they should be composited anyway.
> 
> Bug: 684631,  746018 
> Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
> Change-Id: I354ce936e981e66bcbc59f7248474cd29a9ecf8c
> Reviewed-on: https://chromium-review.googlesource.com/585290
> Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
> Commit-Queue: Yi Gu <yigu@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#490869}

TBR=flackr@chromium.org,chrishtr@chromium.org,yigu@chromium.org

Change-Id: I0a1cba3eb485799f25f5a97cab90d883df9a0c1d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 684631,  746018 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Reviewed-on: https://chromium-review.googlesource.com/595285
Reviewed-by: Jan Krcal <jkrcal@chromium.org>
Commit-Queue: Jan Krcal <jkrcal@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490915}
[modify] https://crrev.com/b5e3fb4ddb04d28f70be4aa455ab60a6b643b913/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp
[modify] https://crrev.com/b5e3fb4ddb04d28f70be4aa455ab60a6b643b913/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/b5e3fb4ddb04d28f70be4aa455ab60a6b643b913/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h
[modify] https://crrev.com/b5e3fb4ddb04d28f70be4aa455ab60a6b643b913/third_party/WebKit/Source/core/paint/PaintLayerScrollableAreaTest.cpp
[modify] https://crrev.com/b5e3fb4ddb04d28f70be4aa455ab60a6b643b913/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

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

commit f18788ff656a564548fb655051116785e35a60b0
Author: Yi Gu <yigu@chromium.org>
Date: Tue Aug 01 17:09:28 2017

Reland "Experiment on not compositing small scrollers"

The previous patch https://chromium-review.googlesource.com/c/585290/
got reverted because it added a unit test which failed Android Nexus 4
bot. For select elements, it looks like that we create paint layers on
most platforms but not on Nexus 4. Therefore ASSERT_TRUE(paint_layer)
failed on that bot. The only difference between this patch and the
previous one is now I use:
 ASSERT_TRUE(!paint_layer || !paint_layer->HasCompositedLayerMapping())
instead of:
 ASSERT_TRUE(paint_layer);
 ASSERT_FALSE(paint_layer->HasCompositedLayerMapping());

Bug: 684631,  746018 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I9d8f68bced170bdb74cacee3aeb3096e99a07b53
Reviewed-on: https://chromium-review.googlesource.com/596207
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#491023}
[modify] https://crrev.com/f18788ff656a564548fb655051116785e35a60b0/third_party/WebKit/Source/core/layout/compositing/CompositingRequirementsUpdater.cpp
[modify] https://crrev.com/f18788ff656a564548fb655051116785e35a60b0/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.cpp
[modify] https://crrev.com/f18788ff656a564548fb655051116785e35a60b0/third_party/WebKit/Source/core/paint/PaintLayerScrollableArea.h
[modify] https://crrev.com/f18788ff656a564548fb655051116785e35a60b0/third_party/WebKit/Source/core/paint/PaintLayerScrollableAreaTest.cpp
[modify] https://crrev.com/f18788ff656a564548fb655051116785e35a60b0/third_party/WebKit/Source/platform/RuntimeEnabledFeatures.json5

Any idea why this is different on N4?

On the right bug this time, bokan came up with a suggestion that we can also just reduce the raster skirt size on these devices which should significantly reduce the additional memory allocated by these scrollers unless they also cause layer explosion. I believe Xida has started experimenting with this - it'd be worth doing this experiment as well since it's an easy change to make.

I have closed issue 748693 and am turning off the first experiment now.
Findings:

(a) GPU memory reduction (GPU.ContextMemory.GLES.Periodic) is 26.7% / 2.7MB->2.0MB at 75th
percentile, and 27.3% / 7.8MB -> 5.7MB at 95th percentile.

(b) Scroll latency regression (Event.Latency.TouchToScrollUpdateSwapBegin) 112.7% regression / 50ms->115 ms at 75th percentile, 331.7% /  135ms -> 580ms at 95th percentile. 

I like the raster skirt reduction idea a lot.  Are we perhaps creating a vertical skirt for these horizontally scrollable input boxes?  In that case, we should just do it without even any experiment necessarily.

Just had a meeting with ericrk@, he pointed out that we are already doing that with the skirt size. The next experiment is to try aggressively reducing the |soft_memory_limit| (1MB) and see how often we do checker-boarding.

I wonder if we could halve the height of tiles on these "reduced" scrollers?

I discussed w/flackr, yigu, xidachen, ericrk, vmpstr and enne about reducing raster skirt (kMaxSoonBorderDistanceInScreenPixels) and also reducing the
soft tile memory limit (*).

Conclusions:

1. Reducing the skirt seems reasonable. It's currently set to 312 screen pixels on all platforms. We should reduce that.
2. Reducing the soft memory limit is the best way to reduce memory.

I think we should land a change to just reduce #1 on low-end Android. Probably ok to just skip the experiment.

Xida is going to run an experiment for #2.

(*) code link: https://cs.chromium.org/chromium/src/content/renderer/gpu/render_widget_compositor.cc?rcl=36353d73147aa8ee4f8da90f2cb779d3aaca5bdc&l=473

To summarize next steps:

1. yigu@ will run an experiment for not compositing small scrollers. Metrics to monitor will be the
same as in issue 748693.

2. xidachen@ will run an experiment to reduce the soft tile memory limit to 1MB. Metrics to monitor will
be Scheduling.Renderer.PendingTreeRasterDuration, GPU.ContextMemory.GLES.Periodic, 
Event.Latency.TouchToScrollUpdateSwapBegin, and checkerboarded tiles. Also, UMAs need to be added for how often prepaint exceeds the soft tile memory limit, and how often we hit the hard tile memory limit.

The experiments should be set up this week and run next week. The week following we can
collect learnings.

Also, turns out Event.Latency.TouchToScrollUpdateSwapBegin already measures hitting
the hard memory limit.

We also might want an experiment to change tile sizes. I'll make a new bug for that.

@chrishtr: As pointed by vollick@, maybe we can try to reduce the tile size to be half height? Maybe in a separate experiment?

re comment 37: yes. ericrk is filing a bug about this now.

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

commit 2479a6281c0d971807d9a0e529553a78802a2597
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Fri Aug 11 00:13:22 2017

Revert "Add a content feature to turn off prefer-compositing-to-lcd-text,"

This reverts commit c3de4bd44dcfed3706d8b4aeac967002d3ca9a16.

Reason for revert: experiment has finished, no need for this flag.

Original change's description:
> Add a content feature to turn off prefer-compositing-to-lcd-text,
> for low-end Android devices.
> 
> TBR=piman@chromium.org
> 
> Bug:  746018 
> Change-Id: I40f0dbddd1efc8a751fc3d48c97446e1f04bbeeb
> Reviewed-on: https://chromium-review.googlesource.com/576607
> Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
> Reviewed-by: Eric Karl <ericrk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#487958}

TBR=chrishtr@chromium.org,piman@chromium.org,ericrk@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  746018 
Change-Id: I4a17b01ebf9f331a601cf7f267aae9254091ce41
Reviewed-on: https://chromium-review.googlesource.com/611062
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Antoine Labour <piman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#493608}
[modify] https://crrev.com/2479a6281c0d971807d9a0e529553a78802a2597/content/public/common/content_features.cc
[modify] https://crrev.com/2479a6281c0d971807d9a0e529553a78802a2597/content/public/common/content_features.h
[modify] https://crrev.com/2479a6281c0d971807d9a0e529553a78802a2597/content/renderer/render_view_impl.cc

https://docs.google.com/a/google.com/document/d/1uMYpGxv9S1W7DqTaPqX2G8PdY938mXG3k6nnolmXNgQ/edit?usp=sharing

This doc contains the experimental results for
* Skip compositing small scrollers
* Reduce soft tile memory limit (result not ready yet)

Summary of the first experiment:
1. If we look at all android devices, the crash/hang rate is very close comparing the control vs experimental group. In terms of memory impact, GPU memory for tiling dropped a little bit (2.9%), the number of active picture layers dropped significantly (29.5%). In terms of performance, it is also very close.

2. If we look at low-memory android devices, the browser crash rate is much lower than the control group, renderer crash/hang rate is close. The memory impact is similar to what we observed in #1. In terms of perfornace, the "TouchTOScrollUpdateSwapBegin" increased by 3.6%, not very significant.

Thanks Xida for the thorough doc!

There is no significant diff in Event.Latency.TouchToScrollUpdateSwapBegin but for some reason the experimental group increases the latency (~5ms) according to Event.Latency.ScrollUpdate.Touch.TimeToScrollUpdateSwapBegin2_Main (it excludes the first scroll events). Oddly, in the latter metric, the sample from the experimental group is way more than the one from the control group (143000 vs 60000 on dev).

p.s. when analyzing data from dev please be aware that the change was landed on dev on August 16 (less than 7 days as of today).

What are the next steps?

We launched experiment of "skip compositing small scrollers" to M62 beta, and the results are captured in this internal doc:
https://docs.google.com/document/d/1uMYpGxv9S1W7DqTaPqX2G8PdY938mXG3k6nnolmXNgQ/edit#heading=h.i7ot5x2gtb60

Here is the summary:
1. There is no statistically significant difference on stability, memory and heartbeat metrics.
2. "Event.Latency.ScrollBegin.Touch.HandledToRendererSwap2_Main" regressed ~100% for all percentiles. The samples from the enabled group is 2x of the control group, which suggests that there is a lot more main-thread scrolling from the enabled group.

I forgot to mention my conclusion in the previous comments. Given that the experiment doesn't have big savings on memory and that scroll on main regressed ~100%, I'd say that we should not enable this on low-end devices.

Makes sense - thanks for the detailed report and analysis.

I'm surprised there isn't more of a difference in memory, but maybe these small scrollers are just not that common overall.

I agree that we shouldn't ship this as it doesn't help unfortunately.
Regarding "not that common" from comment 46: comment 7 indicates that 90% of scrollers are small.
The experiment used a threshold of 160,000px, which is at the 90% threshold.

Closing this bug as WontFix.