All graphs for this bug:
  https://chromeperf.appspot.com/group_report?bug_id=794527

(For debugging:) Original alerts at time of bug-filing:
  https://chromeperf.appspot.com/group_report?sid=ea4aa22be6058e7c78ef2da305a52f0e6cce764f5238f926c05421611326599b


Bot(s) for this bug's original alert(s):

chromium-rel-mac12-mini-8gb

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14a95132040000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14a95132040000

Avoid unnecessary background image tiling
By fmalita@chromium.org · Wed Dec 06 18:00:13 2017
chromium @ d46daceb7047d0ab92a164a062fa26e31baae377

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14b053ca040000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14b053ca040000

Avoid unnecessary background image tiling
By fmalita@chromium.org · Wed Dec 06 18:00:13 2017
chromium @ d46daceb7047d0ab92a164a062fa26e31baae377

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

This is unexpected, but PinPoint is consistent.

Note that the regression only occurs on one specific platform, with GPU rasterization (Mac Mini, Intel GPU).

The change avoids unnecessary background tiling when a single background image tile is sufficient to cover the whole dest area.

For this particular test, the heuristic only triggers for the "Sign me up" button, hidden under the "Follow" floater in the bottom-right corner.  This button uses a gradient background.


Before d46daceb7047d0ab92a164a062fa26e31baae377:

  save
    clipRRect([840.5 835.5 925.5 856.5])
    drawRect([840 835 926 857], SkPictureShader(SkPicture(drawRect(SkLinearGradient))))
  restore


After d46daceb7047d0ab92a164a062fa26e31baae377:

  save
    clipRRect([840.5 835.5 925.5 856.5])
    drawRect([841 836 925 856], SkLinearGradient)
  restore

So we're drawing a smaller rect, with a much simpler shader - I would expect this to be significantly more efficient.

... but: because the element has a border radius, it gets clipped (clipRRect). I suspect Ganesh catches this pattern (save/clipRRect/drawRect/restore) and converts to single drawRRect, IFF the dest rect fully covers the clip.  Since after the change this is no longer the case, I posit we are seeing the effect of an extra clipRRect - which may affect this particular GPU disproportionately.

Ideally, it would be nice for Blink to perform the same power reduction (save/clipRRect/drawRect/restore -> drawRRect).  Short term, I can make the heuristic more conservative and not shrink the dest rect when clipping is applied.

Deleted: follow.png 22.1 KB

	follow.png 22.1 KB View Download

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/14a634ba040000

📍 Found a significant difference after 1 commit.
https://pinpoint-dot-chromeperf.appspot.com/job/14a634ba040000

Add support for jumbo in content/renderer
By bratell@opera.com · Thu Dec 14 14:20:51 2017
chromium @ 8da2ab335438e7a3525efb843eac628c4249dc26

Understanding performance regressions:
  http://g.co/ChromePerformanceRegressions

Go home pinpoint, you're drunk (that was a test run with a CL reverting my change; apparently the diff got blamed on whatever happened to be at HEAD).

*phew* I got scared!

(The new regression UI is different and didn't tell me much)

Sorry, I think the Pinpoint result in comment #8 is https://github.com/catapult-project/catapult/issues/4040 (Regression sensitivity is too high for frame_times)

The other Pinpoint results in #3 and #5 look correct, though.

Thanks for checking Dave.  Yes, blame in c#3/5 is correct.

In c#8 I ran pinpoint with a CL ("Test a patch" button in the bottom-right corner).  My theory of what happened:

- pinpoint ran the test @HEAD, observed current/regressed metric
- pinpoint ran the test @HEAD + CL, observed progressed metric
- pinpoint concluded there is a regression @HEAD ('cause $metric(HEAD) << $metric(HEAD + CL)), and reassigned the bug

I think the failure is pinpoint not treating test runs as distinct from regular/bisect runs.  In test-a-patch mode I don't expect pinpoint to blame/reassign any bugs, but simply produce numbers for HEAD vs. HEAD+CL (which thankfully it did).

It's also possible re-using a completed bisect run to trigger a test run lead to some inconsistent state - maybe the UI could be improved to prevent this if not supported.

fmalita: We've improved the UI for perf try jobs quite a bit, can you take another look?