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

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


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

chromium-rel-win7-gpu-ati

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

📍 Couldn't reproduce a difference.
https://pinpoint-dot-chromeperf.appspot.com/job/14d30d6b040000

📍 Pinpoint job started.
https://pinpoint-dot-chromeperf.appspot.com/job/1182fe47040000

Broadened the revision range.

📍 Found significant differences after each of 2 commits.
https://pinpoint-dot-chromeperf.appspot.com/job/1182fe47040000

Log an UKM event when blocking a cross-site document.
By lukasza@chromium.org · Fri Jan 05 17:58:59 2018
chromium @ f994166392e7fd2f53b2cdf541a2357d7ced3ca9

Add fieldtrial testing for DefaultPassthroughCommandDecoder.
By geofflang@chromium.org · Fri Jan 05 18:11:20 2018
chromium @ 408921af86e70591ea6f05722e49babb6711ef23

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

+tdresser@, the owner of thread_times.tough_scrolling_cases

I don't really know what the testcase does, but:

1. I assume that no network requests are issued during the performance-sensitive part of the testcase (which seems to be about scrolling, not about resource requests)

2. Even if network requests were issued during the sensitive part of the testcase, I would be really surprised if the requests were blocked by the cross-site document blocking (XSDB) logic.

3. And then - XSDB is disabled by default.  For example, the XSDB CL mentioned in #c6 introduces CrossSiteDocumentResourceHandler::LogBlockedResponse, but this method is only called by CrossSiteDocumentResourceHandler::OnReadCompleted if |should_block_based_on_headers_| was earlier set to true (and CrossSiteDocumentResourceHandler::ShouldBlockBasedOnHeaders returns false unless a user opted into a Site Isolation mode - I doubt that tests are doing that, are they?).

Therefore, I am skeptical of the claim from #c6 that says that the bot "found significant differences after [...] f994166392e7fd2f53b2cdf541a2357d7ced3ca9".


Hopefully geofflang@ has better luck understanding the relationship between this regression report and his 408921af86e70591ea6f05722e49babb6711ef23.

I believe it's due to my CL.  I've got some other regressions due to it as well.  Investigating now.

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

commit 471d8d86874d2666ef7aa1ae563ba64aff15b6fb
Author: Geoff Lang <geofflang@chromium.org>
Date: Tue Jan 09 23:36:32 2018

Initialize the gpu_rasterization capability for the passthrough cmd decoder.

Remove double-initialization of flips_vertically.

BUG= 799797 
BUG= 799946 
BUG= 799982 
BUG= 800018 
BUG= 800083 
BUG= 800125 

Cq-Include-Trybots: master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
Change-Id: Idbbd54776b749f0a110ea8515ee61cfad85c3e91
Reviewed-on: https://chromium-review.googlesource.com/857595
Reviewed-by: Zhenyao Mo <zmo@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#528166}
[modify] https://crrev.com/471d8d86874d2666ef7aa1ae563ba64aff15b6fb/gpu/command_buffer/service/gles2_cmd_decoder_passthrough.cc