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

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


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

chromium-rel-win7-gpu-ati
chromium-rel-win7-gpu-nvidia
win-high-dpi

Started bisect job https://chromeperf.appspot.com/buildbucket_job_status/8966180027801792272

=== Auto-CCing suspected CL author robertphillips@google.com ===

Hi robertphillips@google.com, the bisect results pointed to your CL, please take a look at the
results.


=== BISECT JOB RESULTS ===
Perf regression found with culprit

Suspected Commit
  Author : Robert Phillips
  Commit : 3a9305383169524488cb84e9bd5dba95520c3ca7
  Date   : Thu Oct 05 11:31:03 2017
  Subject: Always use draws instead of clears for ANGLE D3D11

Bisect Details
  Configuration: winx64ati_perf_bisect
  Benchmark    : blink_perf.canvas
  Metric       : transferFromImageBitmap/transferFromImageBitmap
  Change       : 21.96% | 57670.0181481 -> 45005.0473867

Revision                             Result                  N
chromium@506714                      57670.0 +- 4017.15      6      good
chromium@506725                      59180.6 +- 4568.51      6      good
chromium@506730                      58233.7 +- 8206.96      6      good
chromium@506730,skia@3a93053831      47016.5 +- 7525.61      6      bad       <--
chromium@506731                      45203.9 +- 7117.0       6      bad
chromium@506732                      47790.3 +- 2048.12      6      bad
chromium@506733                      46897.4 +- 5959.55      6      bad
chromium@506735                      46466.1 +- 5206.21      6      bad
chromium@506755                      45262.3 +- 6022.59      6      bad
chromium@506795                      45005.0 +- 6231.14      6      bad

Please refer to the following doc on diagnosing blink_perf regressions:
  https://chromium.googlesource.com/chromium/src/+/master/docs/speed/benchmark_harnesses/blink_perf.md

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release_x64 --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests blink_perf.canvas

More information on addressing performance regressions:
  http://g.co/ChromePerformanceRegressions

Debug information about this bisect:
  https://chromeperf.appspot.com/buildbucket_job_status/8966180027801792272


For feedback, file a bug with component Speed>Bisection

This is expected. See  crbug.com/768134  and  crbug.com/755871 . Basically, for a wide (probably un-black-list-able) swath of GPUs, clears (both full screen and partial) do not always work with ANGLE/D3D11. To remedy this Skia now replaces clears with drawRects which is slower but seems to work.

Note that ANGLE/D3D9 does not seem to have this problem, nor does directly using gl.

cc-ing test owner junov, and closing as WontFix due to #4. junov, please re-open if more investigation is necessary.

I would actually prefer to leave this bug open. Although there is little we can do right this second there are some longer term things we can do:

In Skia we can try to add some of the optimizations we have for full screen clears to full screen drawRects (i.e., removing all prior draws)

In ANGLE we could try to get a better handle on the issues and see if there is a D3D11 work around.

Thanks. I'm going to remove the Performance-Sheriff label so we don't keep pinging; is there a better component for the bug to live in?

 Issue 773712  has been merged into this issue.

 Issue 773712  has been merged into this issue.

MArk as blocking OffscreenCanvas because perf regression impacts transferFromImageBitmap

robertphillips@: May I know if there's any near-future plans in implementing what's said in comment #7 or is it more like a long-term goal? As of now, this regression is impacting the feature of OffscreenCanvas, that we're planning to release soon.

There is a Skia bug here: skbug.com/7154

After further analysis, the impact of this regression is not that serious for normal OffscreenCanvas use cases. The transferFromImageBitmap benchmark is basically just recycling and clearing GrTextures in a tight loop, so it pretty much isolates the cost of clearing textures. 

Unblocking OffscreenCanvas.

We changed how this workaround is implemented. It used to substitute a rect for a clear at a high level. Now Ganesh tracks it as a clear until flush time. This enables some coalescing that was previously skipped. Some of these regressions have improved substantially, not all the way and not all of them, though. This may be as good as it gets short of figuring out how to not enable the workaround in the first place.

Looks reasonable to me. Are we okay with closing this bug now?

I'm closing this bug since this is as fixed as it is going to get short term.

We still have the Skia bug skbug.com/7154 and the ANGLE bug https://bugs.chromium.org/p/chromium/issues/detail?id=774576 to drive long term perf improvements.