Using the per-revision bisect providing the bisect results,
Good build: 56.0.2900.0(Revision :427219)
Bad build: 56.0.2902.0(Revision:427892)

You are probably looking for a change made after 427481 (known good), but no later than 427482 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
  
https://chromium.googlesource.com/chromium/src/+log/26ce312cc8b3f53dc76df85e45c17bba93685fc3..43de8ce7588866b2ce0eefa9ccf9f570c22f1df7

From the CL above, assigning the issue to the concern owner 

@ericrk - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2447163002

Thanks !

Adding RB Label as this is a recent Regression. Please remove if not required.
Thank You.

So, somewhat counterintuatively, the image here is being downscaled. When you go to 110%, the page switches to its 2x asset and downscales that by 0.55x.

It appears that in this case, the GPU raster downscale is slightly blurrier than the SW raster downscale. Not sure that this is a huge issue - my guess is that there are some scales / images where GPU will look better (due to performing full trilinear filtering) and some cases where SW may look better.

Cases where we really want to maintain sharp edges should probably be using SVG.

For an example of where SW raster's sharpness ends up looking less good, consider the attached image. The top version uses the sharper SW raster downscaling, which leads to aliasing in the cat's whiskers. The smoother GPU raster downscaling does not show this issue.

I'm not sure that we'll be able to be ideal in all situations, and what we have might be fine. bsalomon@, wdyt?

Deleted: downscale comparison.png 72.8 KB

	downscale comparison.png 72.8 KB View Download

I believe the sw is using bilinear filtering not trilinear. This is certainly possible on the GPU but I think in general will look worse. Depending on the GPU we could bias the LOD lookup towards being sharper if we think that would look better. However, I tend to agree with the comment in #3 that if the content is a vector graphic then it would be better to use canvas or svg to draw at display resolution rather than relying on image filtering to preserve sharpness.

So is this a WontFix?  I assume we don't want to use nearest neighbor, as that tends to look pretty awful.  We could alternatively use nearest neighbor and try to adjust image size so it's always upscaled only to integer multiples of its original size, and use nearest neighbor scaling (Does CSS allow that, or woudl we have to switch to a canvas or something?) though that does seem more than a little weird.

I think that this is either WontFix, or we should adjust Skia's LOD bias to be sharper. Sharpening  would have the downside of introducing more aliasing into images. The image in question happens to look better with a sharper downscale, but other types of content (photos) likely won't (see #4).

My preference is to wontfix, and if we want to address this icon on the content side, we could use an SVG or other vector format.