Bug 130818 – Sometimes, GIF pictures are not decoded correctly.

• Status: NEW
• Component: Images

Created attachment 227916 [details]
broken GIF

Version:  webkitgtk-2.4.0. 
Platform: ubuntu 13.10
I have studied this problem for a while. Now I slow down the GIF play by inserting below code into BitmapImage::startAnimation

    if (nextFrame == 0 && m_repetitionsComplete == 0 && m_desiredFrameStartTime < time)
        m_desiredFrameStartTime = time;

+   if(m_repetitionsComplete>5)
+       m_desiredFrameStartTime = time + 2.0;

    if (!catchUpIfNecessary || time < m_desiredFrameStartTime) {

The attached screenshot can proves that some GIF frames are not decoded correctly.
The key of reproducing is to access some GIF of a slow website. 
The one used in my case is http://s1.dwstatic.com/group1/M00/E9/FC/11a75b9231c0572007e1634474f6b4a6.gif

1. No code to check if frame 0 is decoded before starting to decode frame 1
2. BitmapImage::startAnimation() may skips some frames if the animation lags behind the schedule, I am not sure if this may happens for the first round, but if so, this may introduces some decode problem.

The problem scenario should be something like:

1.	Decoder gets some raw data 
2.	Decoder decodes received data and saves decoded data into m_frameBufferCache
3.	Decoded data is used to generate cario surfaces, but cairo does not generate new image data but continue using the data saved in m_frameBufferCache. i.e. cairo surface and decoder share the same memory space. My debug can prove this.
4.	After receive more raw data, decoder has to resize m_frameBufferCache to get more room. 
5.	From the view point of linux system, after resize, the memory space occupied by the image data of some cairo surfaces is FREE now, while cairo has no chance to know it.
6.	These FREE memory are reused
7.	Cairo paints the screen using the polluted  surfaces

Created attachment 229274 [details]
Patch for this problem

Patch for this problem. Only tested on Webkitgtk

[Jeremy Zerfas]

This is the same bug from bug 16200 and bug 111179 . I think the patch in attachment 192693 [details] may work a little better for fixing this problem.