Able to reproduce the issue on mac 10.11 chrome version 52.0.2717.0 - Please find the screenshot.

This looks similar to  Issue 600482 

Pdr@ Could you please confirm if both are same

I don't think it's the same issue as ours, we don't have a blur problem but a rendering one.I tried to degrade to chrome 45 and it didn't work for example.

Thank you for providing more feedback. Adding requester "tkonchada@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This is a severe issue. Makes it impossible to heavily use CSS properties, such as translate3d matrix3d rotate3d, that relies on GPU action.

And it's a shame because they can be used to accomplish great things.

The browser is at 100% GPU memory usage. The image concerns ourjsfiddle example. We used the chrome rendering settings.
Thanks!

Deleted: bug.png 36.4 KB

	bug.png 36.4 KB View Download

And it happens on Mac, Linux, Windows 7/10 (newest chrome versions).

Lets see if a bisect reveals anything.

Able to reproduce the issue on Win7/64 bit, Mac OSX [10.11.4] & Linux/Ubuntu 14.04 - 50.0.2661.87

This is observed when the zoom out level is around 67% or less.

It seems like not a regression issue as this is seen on M47 build Version 47.0.2526.111 as well. Please find the attached screen shot.

Deleted: 606287 Win.PNG 435 KB

	606287 Win.PNG 435 KB View Download

Deleted: 606287 on M47 Build.PNG 538 KB

	606287 on M47 Build.PNG 538 KB View Download

These are directly composited images, which are forced to raster at the
full resolution of the image. It may be the time to kill these things. But
probably in conjunction with a change to re-raster on every frame on scale
change.

As per comment #12 this seems to be a non regression issue. Hence removing the Needs-Bisect label. Please tag the label if required.

Vlad, is this sufficiently awesome now with your work?

No, this is suffering from oom tiles. Image decodes don't really have anything to do with this, it's just trying to display all of that content (with composited images) will cause us to be out of (tile) memory, which is why checkerboards remain there permanently (we also don't have direct picture rendering with the delegated compositor).

The action plan here I believe is to do a heuristic that might do several steps of raster scales so that in this specific situation we'd use as much memory as with non composited images. 

Experiencing the issue too, with even as few as 4-5 JPEGs (though large ones, about 1MB each). 
In my instance, the container on  which I place the images also enables zoom and pan abilities, and using these freezes the entire Chrome process.

[Chrome 40.0.2214.91 on Linux Mint]

After a few tests we tried a div with a background-image (which is not a great workaround) and it worked on a small app:
http://jsfiddle.net/7abx92ke/5/
(You can play with the width and height).

But, on our app, we have our zoom (scene viewer) so we can further zoom out and it still kills the browser, and in other browsers it doesn't.
Maybe our extra example will help you.

Hi, 
Is there any update on the issue in hand? or a workaround? 

Thanks for any feedback.

Hi there,
Any news from April?

Any update? A fix is really needed

No update, sorry.

Hi,
Could you please provide us some information what are you going to do with this bug? 
Are you going to fix it soon?

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

commit c05804da22bca99f807b9198465dbe1318dbfa76
Author: vmpstr <vmpstr@chromium.org>
Date: Mon Jun 27 23:48:50 2016

cc: Change directly composited image raster source scale occasionally.

This patch changes the behavior of directly composited images in the
following way:

- The scale starts at 1.f.
- It is halved if the ideal source scale is less than half of the raster
  scale.
- It is doubled if the ideal source scale is greater than the raster
  scale.

R=enne, chrishtr, danakj
BUG= 606287 
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Review-Url: https://codereview.chromium.org/2100483003
Cr-Commit-Position: refs/heads/master@{#402333}

[modify] https://crrev.com/c05804da22bca99f807b9198465dbe1318dbfa76/cc/layers/picture_layer_impl.cc
[modify] https://crrev.com/c05804da22bca99f807b9198465dbe1318dbfa76/cc/layers/picture_layer_impl_unittest.cc

Thank you very much, when can we test it?

This should be in either today's or tomorrow's canary builds. Please update when you can verify.

We verified the issue and the performance and stability has definitely improved.
The GPU Memory used dropped significantly. 
Still, we are seeing a difference in performance compared to Firefox which appears to render faster: this is mostly visible in our application but also in the above fiddle.
 
Thank you for attending this issue. When is this canary version (53.0.2780.0) expected to be in a stable version?

Hi,
Can we please get an update about the expected date in which this fix will be deployed to a stable release?

Thanks,

This should make it to stable within a few weeks. You can see the current releases on omahaproxy.appspot.com