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

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


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

chromium-rel-win7-dual
chromium-rel-win7-x64-dual
chromium-rel-win8-dual

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

=== Auto-CCing suspected CL author fmalita@chromium.org ===

Hi fmalita@chromium.org, 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 : Florin Malita
  Commit : 8d4d7f4ddabcf5281d5ac7776233570e409d6d3b
  Date   : Mon Jul 24 20:06:05 2017
  Subject: Enable Skia's raster-pipeline radial gradient impl

Bisect Details
  Configuration: win_perf_bisect
  Benchmark    : smoothness.tough_canvas_cases
  Metric       : frame_times/tough_canvas_cases_rendering_throughput_bouncing_svg_images.html
  Change       : 19.95% | 117.352934824 -> 140.768009547

Revision             Result                  N
chromium@488994      117.353 +- 2.60895      6      good
chromium@489043      117.17 +- 3.29793       6      good
chromium@489056      116.883 +- 2.13754      6      good
chromium@489058      116.993 +- 6.54684      6      good
chromium@489059      140.335 +- 5.01778      6      bad       <--
chromium@489062      141.055 +- 4.67988      6      bad
chromium@489068      144.151 +- 5.33017      6      bad
chromium@489092      140.768 +- 5.05774      6      bad

To Run This Test
  src/tools/perf/run_benchmark -v --browser=release --output-format=chartjson --upload-results --pageset-repeat=1 --also-run-disabled-tests --story-filter=tough.canvas.cases.rendering.throughput.bouncing.svg.images.html smoothness.tough_canvas_cases

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

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


For feedback, file a bug with component Speed>Bisection

 Issue 750848  has been merged into this issue.

A small regression was expected with this change, limited to:

1) CPU rasterization
2) radial gradients
3) (Windows?)

The new/raster pipeline impl a) is more correct/exact and b) allows us to drop a significant amount of legacy code.

Assigning to mtklein just in case there's something actionable here, but otherwise I vote for WontFix.

I am not really sure how does the ~%10 regression in the metric translate to actual user impact. So I will leave it up to junov@ to determine if the tradeoff here makes sense.

I think I can make the fix/wont-fix call here.  I'd just like to take a little bit of a deeper look at this before deciding.  Won't be more than a couple days.

Florin, can you take a look at this in a profiler?

The .svg Chrome logo does have a radial gradient in it, but I'm not seeing any significant time spent in software rasterization.  It looks like we're spending most of our time tessellating for GPU path rendering.

There doesn't appear to be any caching going on here at all.  Is that surprising?

Yeah, I'm seeing the same thing with acceleration - most time spent in tessellation.  Kind of surprising to me (the animated path transform is defeating caching?), but that's sort of a separate issue.

I can certainly see the RP gradient stages float to top when running with --disable-accelerated-2d-canvas, so I wonder if that's the case with these Win bots (which would raise questions about their purpose in my mind).

  21.75%  libskia.so                    [.] _sk_load_bgra_hsw
  13.58%  libskia.so                    [.] _sk_from_srgb_hsw
   8.54%  libskia.so                    [.] _sk_to_srgb_hsw
   7.59%  libskia.so                    [.] _sk_matrix_3x4_hsw
   6.72%  libskia.so                    [.] _sk_clamp_1_hsw
   5.07%  libskia.so                    [.] _sk_store_bgra_hsw
   3.61%  libskia.so                    [.] _sk_clamp_0_hsw
   3.34%  libpthread-2.25.so            [.] pthread_mutex_init
   3.25%  libbase.so                    [.] tracked_objects::TaskStopwatch::TaskStopwatch
   2.49%  libskia.so                    [.] sse41::blit_row_s32a_opaque
   2.36%  [kernel]                      [k] clear_page_erms
   2.18%  libcc.so                      [.] cc::benchmark_instrumentation::ScopedBeginFrameTask::ScopedBeginFrameTask
   2.17%  libskia.so                    [.] _sk_unpremul_hsw

@junov, do you happen to know if these bots/tests are running with accelerated c2d?

I had not realized that non-accelerated canvas was still a supported mode!  I'd have thought we'd go through swiftshader instead?

That's a very provocative set of stages we see there on the top of the profile.  Looks like a colorspace transform?  This doesn't look a blitting profile to me.  It'd be rare to see load_bgra unless it were a sprite blit, rare to see matrix_3x4 unless we somehow decided to do a live gamut transform, and rare to see unpremul generally.

Do you see any stages related to gradients?  Whether or not we're drawing with software, I'm still struggling to see how a change to gradients affected this so noticeably when we don't see the gradient ever happening on the profile.

I've upgraded my Linux box and perf top is now finicky for me - super volatile between refreshes, so I wouldn't take the actual numbers at face value.  But yeah, the gradient stage shows up every now and then:

   4.42%  libskia.so                    [.] SkAAClipBlitter::blitAntiH
   3.81%  libskia.so                    [.] SuperBlitter::blitH
   3.56%  libskia.so                    [.] _sk_from_srgb_hsw
   3.46%  libskia.so                    [.] SkScan::AAAFillPath(SkPath const&, SkRegion const&, SkBlitter*, bool)::$_0::operator()
   3.33%  [kernel]                      [k] decay_load
   3.25%  libskia.so                    [.] _sk_store_bgra_hsw
   3.06%  libskia.so                    [.] _sk_to_srgb_hsw
   3.02%  libskia.so                    [.] _sk_load_bgra_dst_hsw
   2.98%  libskia.so                    [.] _sk_dither_hsw
   2.85%  libskia.so                    [.] _sk_matrix_3x4_hsw
   2.31%  [kernel]                      [k] __update_load_avg_se.isra.28
   1.90%  libskia.so                    [.] _sk_gradient_hsw
   1.85%  libskia.so                    [.] SkAAClip::Builder::addRun
   1.79%  libskia.so                    [.] _sk_clamp_1_hsw
   1.64%  libskia.so                    [.] _sk_start_pipeline_hsw
   1.58%  [kernel]                      [k] __mod_node_page_state
   1.57%  libskia.so                    [.] _sk_load_bgra_hsw

You may get more stable numbers on a Mac.

Now that looks like a blit.  Any load_..._dst is kind of a giveaway.

The surprising bit is that it's doing to_srgb.  If the destination is tagged as sRGB, your this CL shouldn't actually have opted the gradient into SkRasterPipeline... it should already have been using it from like, day 1.

Starting up again now with Instruments and --disable-accelerated-2d-canvas.

So I just dug up the bot logs and...

INFO) 2017-08-14 19:19:24,063 browser._LogBrowserInfo:117  Browser started (pid=4056).
(INFO) 2017-08-14 19:19:24,063 browser._LogBrowserInfo:120  OS: win win7
(INFO) 2017-08-14 19:19:24,063 browser._LogBrowserInfo:123  Detailed OS version: 6.1.7601
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:132  GPU device 0: VENDOR = 0x102b, DEVICE = 0x532
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:134  GPU Attributes:
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    adapter_luid        : 0.0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    amd_switchable      : False
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    basic_info_state    : 1
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    context_info_state  : 0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    direct_rendering    : True
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    driver_date         : 6-21-2006
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    driver_vendor       : Microsoft
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    driver_version      : 6.1.7600.16385
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    dx_diagnostics_info_state: 0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_extensions       : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_renderer         : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_reset_notification_strategy: 0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_vendor           : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_version          : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_ws_extensions    : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_ws_vendor        : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    gl_ws_version       : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    in_process_gpu      : True
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    initialization_time : 0.0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    jpeg_decode_accelerator_supported: False
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    lenovo_dcute        : False
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    max_msaa_samples    : 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    optimus             : False
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    pixel_shader_version: 
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    process_crash_count : 0
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    sandboxed           : False
(INFO) 2017-08-14 19:19:24,072 browser._LogBrowserInfo:136    software_rendering  : False
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:136    vertex_shader_version: 
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:136    video_decode_accelerator_flags: 0
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:138  Feature Status:
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    2d_canvas           : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    flash_3d            : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    flash_stage3d       : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    flash_stage3d_baseline: unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    gpu_compositing     : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    multiple_raster_threads: unavailable_off
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    native_gpu_memory_buffers: disabled_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    rasterization       : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    video_decode        : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    video_encode        : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    vpx_decode          : unavailable_software
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    webgl               : unavailable_off
(INFO) 2017-08-14 19:19:24,073 browser._LogBrowserInfo:140    webgl2              : unavailable_off

https://luci-logdog.appspot.com/v/?s=chrome%2Fbb%2Fchromium.perf%2FWin_7_Perf%2F1054%2F%2B%2Frecipes%2Fsteps%2Fsmoothness.tough_animation_cases.reference_on__102b__GPU_on_Windows_on_Windows-2008ServerR2-SP1%2F0%2Fstdout


So we're running these benches in SW -- which is surprising to me considering the step name is "smoothness.tough_canvas_cases on (102b) GPU on Windows on Windows-2008ServerR2-SP1" :)

At least it explains why they're sensitive to RP changes.

Fun.

I think I've sorted out what's up with the various raster pipeline stages.

When we're drawing in Chrome's color correct mode, we snap <canvas> and convert it over to the display color space using SkColorSpaceXformCanvas.  Given the profile I'm seeing, we must be treating <canvas>'s surface as sRGB (and oddly, treating my Adobe RGB monitor as Adobe RGB gamut with sRGB transfer function, a white lie).

Any from_srgb, to_srgb, matrix_3x4, stages are explained by that.

If I switch my monitor color profile over to straight sRGB, I see the profile dominated by the normal Skia drawing functions: scan converter, various super-and-not blitters, and gradient draw stages: xy_to_radius, gradient, seed_shader, matrix_2x3, dither, load_bgra_dst, store_bgra.

I feel like we're now pretty well into don't-care territory here, basically about all canvas benchmarks run on this bot.  Agreed?

There are Windows bots that _do_ run with hardware 2D canvas, right?

I certainly hope we have some accelerated C2D bots;  all bots associated with this bug seem to run smoothness.tough_canvas_cases in SW mode though: chromium-rel-win7-dual, chromium-rel-win7-x64-dual, chromium-rel-win8-dual.

Agreed that we probably don't care much about this case -- closing, unless junov feels otherwise.

 Issue 750846  has been merged into this issue.