Xida is currently looking at touch-action related stuff. It looks like the codepen page manages to have a number of touch event listeners, which we are assumedly updating at 60fps despite nothing having really changed.

We have a lot of touch event rects on this page which are not merged because they're in separate composited layers. I think there's two issues here:
1. Why are the touch event rects dirty each frame? The animation seems like it should have no effect on them.
2. Updating the touch event rects seems overly expensive. There are a few things that stand out as potentially expensive but so far my attempts to benchmark in the page haven't given a clear offender.
  - For each touch event target, we check whether each ancestor of it is in the set of targets. https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.cpp?type=cs&l=1110
  - For each target, we do a walk to check whether it is contained within a scroller
  - For each target, we walk up the tree to accumulate the offset to the enclosing composited layer https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/page/scrolling/ScrollingCoordinator.cpp?type=cs&l=1110

I suspect that determining the rect positions will be simpler in spv2, but it seems like some of these tree walks may be redundant.

Some more investigation:
1. The page has a non-composited animation: stroke-dashoffset, so that's why it has to update layout every frame. That makes the code path go into ScrollingCoordinator::UpdateTouchEventTargetRectsIfNeeded().

2. Locally, UpdateTouchEventTargetRectsIfNeeded() takes 0.423ms on average. It does ComputeTouchEventTargetRects() which takes 0.061ms and SetTouchEventTargetRects() which takes 0.348ms.

3. In SetTouchEventTargetRects() function, ProjectRectsToGraphicsLayerSpace() takes 0.156ms and the for loop after that takes 0.149ms. So these two things are definitely the primary target.

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

commit 07ca939ed0a0f50c871809e8c2d8245c50713142
Author: Xida Chen <xidachen@chromium.org>
Date: Fri Jul 28 01:48:24 2017

Improve performance of WebLayerImpl::SetTouchEventHandlerRegion

In the current implementation, this function calls TouchActionRegion:Union
in a for loop. TouchActionRegion::Union does two things:
1. Union the passed-in rect into a Region
2. Union the passed-in rect into a map<TouchAction, Region> based on the
   passed-in TouchAction.

This function is OK if all the passed-in rects has different touch action.
However, the performance could be poor if all the rects have the same
touch action.

This CL aims to improve the performance of SetTouchEventHandlerRegion.
Instead of calling TouchActionRegion::Union, we add a new constructor for
TouchActionRegion which takes a map<TouchAction, Region>. We build the
map first, and then pass it to the constructor. In the constructor, we
union the regions for all the possible touch actions in the map.

In the example page provided in the bug report, we have 105 rects with
the same TouchAction, this makes SetTouchEventHandlerRegion slow. I did
tracing in my local desktop station, and with the current implementation,
this function takes 0.07ms on average. With this CL, this function takes
0.038ms on average.

Bug:  718271 
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Iaef206102074ed1149069040b23484a76d898f19
Reviewed-on: https://chromium-review.googlesource.com/582568
Commit-Queue: Xida Chen <xidachen@chromium.org>
Reviewed-by: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#490194}
[modify] https://crrev.com/07ca939ed0a0f50c871809e8c2d8245c50713142/cc/blink/web_layer_impl.cc
[modify] https://crrev.com/07ca939ed0a0f50c871809e8c2d8245c50713142/cc/layers/touch_action_region.cc
[modify] https://crrev.com/07ca939ed0a0f50c871809e8c2d8245c50713142/cc/layers/touch_action_region.h
[modify] https://crrev.com/07ca939ed0a0f50c871809e8c2d8245c50713142/cc/layers/touch_action_region_unittest.cc

Did this change land in a stable release? I only see that a changeset was merged.

This will be fixed once PaintTouchActionRects shipped.

PaintTouchActionRects is shipped.

Re-open because we revert the ship of PaintTouchActionRects.

PaintTouchActionRects has been shipped