There's a million closed issues on this topic, with the verdict of being 'fixed'. Obviously, it has not been fixed. Please take this problem seriously for once.

Able to reproduce the issue. Followed the below steps:

1) Navigated to Site: http://giphy.com/
2) Observe task manager for the tab "http://giphy.com/"
3) Observed that memory is increased and varies in between 700 to 900 MB within no time. Issue is observed from M33 - 33.0.1713.0. 

Issue is observed on MAC, Windows and Linux OS. 

Untriaged it so that it gets addressed.

My old notebook has also this problem.
When opening a page which contains a lot of gif images, the CPU temperature will get very high and makes a wierd noise.
Also the high CPU temperature may cause os to crash.

Can chrome provide a mechanism to throttle the gif image animations' update frequency, so that event a page contains a lot of gif images, the CPU temperature will still stay COOL?

I have a simple idea to quickly fix this: let chrome default to display only the first frame of gif image, and only animate it when mouse hovers it.

Recently web has treat `muted` <video> as animated images, and will `autoplay` it like a animated image. The reason is simple: mp4 files are encoded more efficiently than gif.

But i'm thinking why cannot treat it `BACK`: that is to say, treat gif images like video, only `play` it when it got user gestures input...

Out of curiosity I did an ETW profile of http://giphy.com/.
Here is what I found:
- Decoding seems to be only 9% of CPU cost of the renderer process. 
- Raster (cc.dll!cc::DrawingDisplayItem::Raster) is 32% with 2/3 of that (22% of the total) is exclusively in SkARGB32_Shader_Blitter::blitRect.
- Painting the tree is 36% of the total CPU cost (blink_core.dll!blink::FrameView::paintTree + blink_core.dll!blink::FrameView::prePaint).

One of the reasons for slow performance may be very high number of context switches.
Here is what I see in Chrome Task Manager in "Idle Wake Ups" column:
- Browser  - 1100-1300 / sec
- GPU      - 3000-3300 / sec
- Renderer - 1600-1700 / sec

Overall -  to 6000 context switches per second.
For comparison, Edge does ~2000 context switches per second.

One of the reasons for high number of context switches in polling in GPU process - GpuCommandBufferStub::ScheduleDelayedWork which seems to be scheduling several delayed tasks per frame on this page.

I'll take this and see if I can figure it out. 
I've removed Internals>Images>Codecs component since #8 shows that only 9% of CPU cost is in decoding. 
GpuCommandBufferStub::ScheduleDelayedWork is a more interesting suspect to pursue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

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

All of the painting costs have gone away since this bug was filed, so this should be cheaper.  Mouse-hovered gifs are not going to be web compatible, and so that's not really a direction we could go.

I think this particular bug is similar to a lot of other issues (e.g.  issue 779534 ), so I'm going to dupe it.