I am adding a small video screen capture of the test case file in action, with the described issue shown.

Deleted: bug-report-visual-example.mp4 3.6 MB

	bug-report-visual-example.mp4 3.6 MB View Download

Able to reproduce the issue on reported version 62.0.3202.97 but the same is not seen on latest Canary 64.0.3276.0, latest beta 63.0.3239.59 using Mac 10.13.1(Intel HD Graphics), Windows 10 and Ubuntu 14.04.

Bisect Info:
------------
Good Build: 63.0.3234.0
Bad build: 63.0.3233.0

We are unable to find the bad behaviour when running per-revision bisect script even after increase the range to +100. Hence providing change log from Omahproxy.

As we are unable to find the suspect from change log, request someone to take a look at this issue and assign to the right owner

Change log (from Omahaproxy): https://chromium.googlesource.com/chromium/src/+log/63.0.3233.0..63.0.3234.0?pretty=fuller&n=10000

Thanks!!

From the report it sounds like something in that range made it better, possibly countering an earlier regression. Maybe a bisect between 59.0.3071.86 and 62.0.3202.97 would be worthwhile too.

In the 59.0.3071.86 and 62.0.3202.97 range I bisected it down to:

https://chromium.googlesource.com/chromium/src/+log/759c905692ffb2e4ebe2efbdbb54b68e4bc97f47..ba0dc30b56da91c890f0d976f590a2dff24b36b5

where baff39d10685ef1abed65771cde8a49f913a7d33 looks like a possible culprit.

A narrow bisect of the 63.0.3233.0 to 63.0.3234.0 landed at:

https://chromium.googlesource.com/chromium/src/+log/1cceec1268d60f1fa986301722efcf99bb2ebb9f..4547f1c5cc664a1ed905a2ab61857596aad16d8d

where 7ae9c79df94293c1a62eaf0a16160603ab382200 appears to be the most interesting.

Its definitely a skia issue. I captured a couple of traces with and without 7ae9c79df94293c1a62eaf0a16160603ab382200.

Before this change, decoding and drawing of images in shaders was completely internal in skia. Here is a trace attached with it and looks like each drawImage operation takes up to ~100ms. And its not doing a decode, the raster tasks where the decode is happening are clear from the corresponding blink decoder trace.

After this change, the image is decoded by cc and the original decoded image is handed off to skia during raster. drawImage operations in these cases still take up to ~20ms.

I've attached both the traces here. fmailta@, could I assign this to you for investigating in skia?

Deleted: trace_cc_cache.json.gz 3.2 MB

trace_cc_cache.json.gz 3.2 MB Download

Deleted: trace_no_cc_cache.json.gz 2.5 MB

trace_no_cc_cache.json.gz 2.5 MB Download

baff39d10685ef1abed65771cde8a49f913a7d33 switched Skia's software HQ image scaling to raster pipeline, which is indeed expected be slower.

But this was not expected to affect Chrome, because since [1] we're not supposed to use HQ for scaling images anymore.  I assume the problem was HQ image scaling requests could still sneak through via picture shaders - hence the regression.  

[1] https://chromium-review.googlesource.com/c/chromium/src/+/541609


Then 7ae9c79df94293c1a62eaf0a16160603ab382200 came along and fixed the picture shader path.  At this point Skia should not be handling any HQ image scaling requests, right?

It would be interesting to compare with pre-baff39d10685ef1abed65771cde8a49f913a7d33 and see what the perf delta is.  It's also possible other regressions occurred in the baff39d10685ef1abed65771cde8a49f913a7d33-7ae9c79df94293c1a62eaf0a16160603ab382200 window.

khushalsagar@ where do you see those ~20ms drawImage calls?  Poking around trace_cc_cache.json.gz I only see ~5.7ms:

Title	void SkCanvas::drawImageRect(const SkImage *, const SkRect &, const SkRect &, const SkPaint *, SkCanvas::SrcRectConstraint)
Category	disabled-by-default-skia

Start	
6,914.833 ms
Wall Duration	
5.715 ms
CPU Duration	
5.717 ms

Attaching local machine traces for chrome@487892 (pre-baff39d10685ef1abed65771cde8a49f913a7d33), chrome@487897 (baff39d10685ef1abed65771cde8a49f913a7d33-7ae9c79df94293c1a62eaf0a16160603ab382200), chrome@519676 (post-7ae9c79df94293c1a62eaf0a16160603ab382200 / ToT).


Someone more familiar with traces should check my reading, but AFAICT:

                        487892        487897        519676

drawImageRect (ms)   4.1 - 4.8       44 - 55     2.7 - 3.6
frame time    (ms)         ~60         ~1200         40-50

So it seems to me we are in a better spot currently than before 7ae9c79df94293c1a62eaf0a16160603ab382200 (thanks to khushalsagar@'s change, for sure).  What regression are we trying to investigate/fix, isn't everything fully recovered @ToT?


(I can think of ways to improve the pipeline for this test: a) do we really need picture shaders in this scene?; b) why are the raster threads hammering on drawPicture instead of hitting the cached picture shader tile; is there a uid/caching issue?  -- but that's a different discussion from this regression bug)

Deleted: trace_487892.json.gz 1.7 MB

trace_487892.json.gz 1.7 MB Download

Deleted: trace_487897.json.gz 1.2 MB

trace_487897.json.gz 1.2 MB Download

Deleted: trace_519676.json.gz 2.4 MB

trace_519676.json.gz 2.4 MB Download

The OP/reporter stated:

> I have additionally tested the issue in Chrome Canary (currently 64.0.3275.0) and have found that the performance issues are greatly reduced in this version, but are still impacted to a degree.

but it seems no one on our side is able to confirm that observation (I didn't notice anything that indicate it hadn't recovered when bisecting the various ranges.) It's not easy to (visually) differentiate 16-17 fps from ~20 though, and other factors could easily have a (small) effect there.

Could the original reporter perhaps consider rechecking with M64/Canary?

Indeed, it's hard to compare visually - a non-subjective measurement would help.  Maybe traces of FPS counter?

It occurred to me that we didn't test far enough: the reporter refers to 59.0.3071.86 as the good version, so we're missing that data point.

Unfortunately, when trying 59.0.3071.86 (chrome@464640), the actual image geometry is different (smaller image), so it's hard to compare apples to apples.

I'll dig around intermediate versions looking for one that renders correctly and hopefully exhibits better perf.

I was able to work around the geometry problem (looks like a resize issue, reload works), attaching traces for chrome@464640 (roughly 59.0.3071.86).

Skia traces are not available for that version, but frame times appear to be similar to Canary/ToT: 40-47ms.

So it doesn't look like we missed any hidden regressions, and Canary perf should be comparable to 59.0.3071.86 based on frame times.

Deleted: trace_464640.json.gz 1.2 MB

trace_464640.json.gz 1.2 MB Download

It was a bit suspect that 7ae9c79df94293c1a62eaf0a16160603ab382200 fixed it since if it was all about using a cached scaled decode from cc during raster, I'd expect to see the decode task to be proportional to the work in skia. But in the trace it didn't look like a decode was happening during raster.

It looks like cc's cache is also clamping the filter quality to medium. Do we still specify high quality when recording in blink so that's what ends up getting used when the decode/scale happens in skia? May be that explains it.

Yes, Blink "default" is still high quality:

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/GraphicsTypes.h?type=cs&sq=package:chromium&l=66

(As used by https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/style/ComputedStyle.cpp?type=cs&sq=package:chromium&l=889 which is the usual source of quality.)

CC limits quality to medium, since https://chromium-review.googlesource.com/c/chromium/src/+/541609.

So as long as CC handles scaling, we avoid any HQ requests to Skia.

Prior to 7ae9c79df94293c1a62eaf0a16160603ab382200 HQ scaling could still sneak through via picture shaders.  Now, all scaling should be <= kMedium_SkFilterQuality.

For this particular test, all drawImageRect calls to Skia are now using kLow_SkFilterQuality (since all images are pre-scaled by CC).

Should blink be switched to match cc? There are still code-paths that don't go through cc for image decoding/scaling (canvas for example) and will create obscure differences like this.

Sounds good, although IIUC the plan is for pretty much everything (other than canvas?) to be scaled/decoded in cc.

Looking closely at the current traces, I do think we're doing some seriously redundant work though: every single RasterTask is re-rasterizing the picture.  This is not just inter-frame, but even within the same frame?!  So it's a drawImageRect(1266x753) raster-fest - which even with kLow is bound to be expensive.

(this could explain differences in perceived perf: a less powerful machine may start choking on so much work)

At a quick glance, what's going on is we're using ephemeral picture shaders and picture image generators, created on the fly during playback:

  PaintOpBuffer::Playback
    ScopedImageFlags::ScopedImageFlags
      ScopedImageFlags::DecodeRecordShader
        PaintShader::CreateDecodedPaintRecord
          PaintShader::CreateSkShader
            SkImage::MakeFromPicture/SkShader::MakePictureShader

So Skia never gets to see the same image/picture ID twice and is forced to raster from scratch every single time => poor perf and internal cache thrashing.

Ideally, the Skia picture-shader/picture-image should be persistent and only change when the content (nested decoded images) changes.

Deleted: picture_thrashing.png 71.1 KB

	picture_thrashing.png 71.1 KB View Download

Re "Should blink be switched to match cc"? Yes please!

I'm putting up a patch for #19 now.

Sigh. Re #18, the problem is being able to replace the image in the recording with a decode from cc's cache when skia internally rasterizes the picture. I couldn't think of any way other than creating a new picture and replacing images with decodes to create a new picture shader. Is there something else in skia we could use instead?

Also, the plan is to do it for everything that is rasterized in cc. The last remaining use case is filters, which is actively being eliminated. But canvas, which in many cases is rasterized in blink, will continue relying on skia.

Creating a new picture shader or image when the picture changes is fine/idiomatic.  But in this case the decoded images do not change a) within the same frame or even b) inter-frame.  Ideally we would reuse the same picture.

Hand-waving a couple of ideas:

* instead of playback time, perform a image decode/scale substitution pass once, before rasterization, and pass the same/transformed/immutable paint_op_buffer to all raster threads (should fix intra-frame picture thrashing)

* cache paint-record image substitution results, and somehow track the substitution params (list of swapped skimage IDs?); then detect identical substitutions and reuse cached results (should fix both intra/inter frame thrashing but potentially more involved)

The problem with caching transformed pictures/PaintOpBuffers is that you have to invalidate them when any of the substituted images are evicted. And this tracking is not trivial, but possible. I was initially hoping for a SkDrawableShader, so we could use a PaintOpBuffer for playback instead of having to transform it into a picture, and then the transformation could be done during playback as it happens for regular raster.

But, I think it would also be wasteful to pre-decode images in cc when skia is caching the rasterized picture. We'll have cases where the decode wasn't necessary because the rasterized picture was already available in skia's cache. May be we should do the rasterization itself in cc as the pre-decode step and give an SkImageShader to skia. This was also a consideration when implementing this.

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

commit be41949577b1848627b782585d01c8edd79e93b7
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Thu Nov 30 00:18:48 2017

Remove all uses of high-quality image filtering in Blink.

The main rendering paths through the compositor already force medium quality
(there was a blink-dev discussion about this). The effect of this CL is that
all rendering paths that are not rastered in the compositor no longer
use a high-quality image filter. This includes drag images and potentially
Canvas.

Bug:  788075 
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I3b6ca29ad67b3d86176a43e0e404c7d50ed14883
Reviewed-on: https://chromium-review.googlesource.com/794874
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Justin Novosad <junov@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520324}
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/fast/reflections/reflection-masks-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/fast/reflections/reflection-masks-opacity-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/fast/reflections/reflection-with-zoom-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/http/tests/devtools/layers/layer-canvas-log-expected.txt
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/mac/css3/masking/mask-repeat-space-padding-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/mac/fast/backgrounds/background-repeat-with-background-color-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/mac/svg/custom/convolution-crash-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/win/css3/masking/mask-repeat-space-padding-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/win/fast/backgrounds/background-repeat-with-background-color-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/platform/win/svg/custom/convolution-crash-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-amplitude-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-exponent-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-intercept-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-offset-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-slope-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-tableValues-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-dom-type-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-amplitude-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-exponent-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-intercept-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-offset-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-slope-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-tableValues-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEComponentTransferElement-svgdom-type-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-bias-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-divisor-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-edgeMode-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-in-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-kernelMatrix-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-kernelUnitLength-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-order-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-preserveAlpha-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-targetX-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-dom-targetY-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-bias-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-divisor-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-edgeMode-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-in-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-kernelMatrix-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-kernelUnitLength-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-order-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-preserveAlpha-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-targetX-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFEConvolveMatrixElement-svgdom-targetY-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-dom-in-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-dom-kernelUnitLength-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-dom-specularConstant-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-dom-specularExponent-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-dom-suraceScale-attr-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-inherit-lighting-color-css-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-lighting-color-css-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-svgdom-in-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-svgdom-specularConstant-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-svgdom-specularExponent-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/dynamic-updates/SVGFESpecularLightingElement-svgdom-suraceScale-prop-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/LayoutTests/svg/filters/feDisplacementMap-expected.png
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/core/clipboard/DataTransfer.cpp
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/core/page/DragController.cpp
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/platform/DragImage.h
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/platform/graphics/GraphicsContext.cpp
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/platform/graphics/GraphicsTypes.h
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/platform/graphics/skia/SkiaUtils.cpp
[modify] https://crrev.com/be41949577b1848627b782585d01c8edd79e93b7/third_party/WebKit/Source/platform/graphics/skia/SkiaUtils.h

Re: Comment #10

I apologize for taking so long to respond - I've re-tested using Canary 65.0.3293.0 and do not see any improvement since the time of reporting (which was using 62.0.3202.97). I have noticed that the size of my browser window plays a role in determining if the behaviour is seen. For example, at 1920x900 the performance is greatly impacted, whereas at 1280x700 there is no visible impact on performance.

I tried looking into how to generate trace files so that I could perhaps be of more assistance, but I am struggling to figure that out.. I created a trace, though I didn't know which settings I would need to enable to show the issue, and additionally whenever I attempted to save the trace file my browser would freeze. If me generating a trace file would be helpful, I'd be happy to try again as long as someone can provide me with some guidance in doing so.

I did, however, attempt to record the behaviour using the 'Performance' tab in the DevTools, and it looks to me that at the start of the animation the FPS was around 20-24, though once the animation was in progress, that dropped down below 10.. at the absolute worst I saw it bottom out at 2.

Please let me know if there's any more details I can provide, or anything more I can do to help.

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

commit 90b79a26fcccb656317b63fcb2da2f4503cbc596
Author: Adrienne Walker <enne@chromium.org>
Date: Tue May 08 21:40:42 2018

cc: Cache picture shaders on the service side

Skia caches the results of SkPictureShaders internally based on its
fUniqueId.  In order to correctly hit that cache, the gpu process
needs to cache and reuse SkPictureShader objects where possible.

One possibility is to use the transfer cache for this (as was done
for SkPaths).  However, paint record shaders can transitively include
images, paint records, other paint record shaders, paths.  Using the
transfer cache would mean having to support transfer cache dependency
graphs, which would make future parallelization more complicated.
Maybe we can punt on this forever, but definitely punt for now.

This patch deliberately chooses a hacky workaround to avoid this
design snag.  In particular, we always serialize the entire
PaintRecord in the shader along with images (at the correct scale).
On the gpu service side, if this shader matches the same scale
and colorspace of the last time we used it, we use the cached
SkShader, otherwise we'll build a new one.

Matching the scale is for visual correctness (as images at different
scales might look visually worse).  Matching the colorspace is for
performance (to avoid unnecessary colorspace conversions) but also
for visual correctness (colorspace conversion causing quality
degradation).

Performance for this is tricky to test.  Animometer has no picture
shaders at all.  One bug that regressed when shaders were not being
cached was the test case attached in  http://crbug.com/788075 .  Switching
images back and forth on that test page had the following results:
  * gpu raster: 32.7ms/frame
  * oop raster: 29.7ms/frame
  * oop raster + patch: 26.0ms/frame (18% improvement over gpu raster)

Bug:  815022 ,  788075 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;luci.chromium.try:win_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I350b1ed6ad90f8c660b1a47444f984ef309ae555
Reviewed-on: https://chromium-review.googlesource.com/1037770
Commit-Queue: enne <enne@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Reviewed-by: Eric Karl <ericrk@chromium.org>
Reviewed-by: Khushal <khushalsagar@chromium.org>
Cr-Commit-Position: refs/heads/master@{#556968}
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/BUILD.gn
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_buffer.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_buffer.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_buffer_serializer.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_buffer_unittest.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_reader.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_reader.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_op_writer.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_shader.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/paint_shader.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/scoped_raster_flags.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/scoped_raster_flags.h
[add] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/shader_transfer_cache_entry.cc
[add] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/shader_transfer_cache_entry.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/skia_paint_canvas.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/skia_paint_canvas.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/transfer_cache_deserialize_helper.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/transfer_cache_entry.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/paint/transfer_cache_entry.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/test/transfer_cache_test_helper.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/cc/test/transfer_cache_test_helper.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/gpu/command_buffer/service/gles2_cmd_decoder.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/gpu/command_buffer/service/raster_decoder.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/gpu/command_buffer/service/service_transfer_cache.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/gpu/command_buffer/service/service_transfer_cache.h
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/ui/gfx/color_space.cc
[modify] https://crrev.com/90b79a26fcccb656317b63fcb2da2f4503cbc596/ui/gfx/color_space.h

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

commit 868717cedf7ffa79d2b248712ee45095ae9831e0
Author: Lei Zhang <thestig@chromium.org>
Date: Wed May 09 04:33:56 2018

Fix jumbo build in cc/paint after r556968.

Also rename globals from "g_foo_" to "g_foo" since they are not member
variables.

Bug:  815022 ,  788075 
Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I5ecee5b3559572dc2f700ad8ae8eb784fc298456
Reviewed-on: https://chromium-review.googlesource.com/1050872
Commit-Queue: Mostyn Bramley-Moore <mostynb@vewd.com>
Reviewed-by: enne <enne@chromium.org>
Cr-Commit-Position: refs/heads/master@{#557091}
[modify] https://crrev.com/868717cedf7ffa79d2b248712ee45095ae9831e0/cc/paint/paint_image.cc
[modify] https://crrev.com/868717cedf7ffa79d2b248712ee45095ae9831e0/cc/paint/paint_shader.cc

Able to reproduce this issue on reported version 62.0.3202.97 using Ubuntu 17.10, hence verifying the fix on latest canary 68.0.3426.0.

Now observing no delay while navigating using arrow icons.

Unable to reproduce this issue on Mac 10.13.3,10.12.6 and Windows 10. Hence unable to verify the fix on Windows and Mac.

@thestig: Please help in verifying the fix on latest canary using Windows and Mac.

Thanks!