Bug 109395 – Poor animated gif performance

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Images

[Philip Rogers]

We currently block while decoding images. This isn't a problem for small images, but large animated gifs (like those found on tumblr) destroy scroll performance.

Repro case:
1) visit http://philbit.com/animatedgiftest.html
2) resize the browser window so you can scroll
3) scroll (or, try to)

For serious sadness, try this on a mobile device.

A profile shows most our time is being spent in GIFImageDecoder and GIFImageReader. We share Gecko's gif decoder and Firefox is able to scroll fairly smoothly on the repro page above, so I think there may be low hanging fruit here outside the decoding infrastructure.

[Philip Rogers]

I learned on IRC that some of these issues are lessened with impl-side painting.

For the tumblr usecase, off-thread decoding may still be worth looking at in parallel because it would prevent large images from blocking the composite.

[noel gordon]

(In reply to comment #0)
> We currently block while decoding images. This isn't a problem for small images, but large animated gifs (like those found on tumblr) destroy scroll performance.

1) about:flags

2) Enable : Threaded compositing Mac, Windows, Linux
Uses a secondary thread to perform web page compositing. This allows smooth scrolling, even when the main thread is unresponsive.

3) load http://gcfly.org/viewthread.php?tid=5721

can you scroll?

[Tom Hudson]

I don't know if it's the case here yet, but historically we've frequently had this kind of behavior when we ran out of image cache; it's something to check for for.

[Allan Sandfeld Jensen]

We start gif animations when they move into the viewport but we never stop them again, which leads to more and more git animations running. This is fixed in bug 112327

[Said Abou-Hallawa]

This is the same as https://bugs.webkit.org/show_bug.cgi?id=161566.

*** This bug has been marked as a duplicate of bug 161566 ***