Bug 130818 - Sometimes, GIF pictures are not decoded correctly.
Summary: Sometimes, GIF pictures are not decoded correctly.
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Images (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
Depends on:
Reported: 2014-03-26 20:55 PDT by arkuka_reg
Modified: 2015-08-09 09:54 PDT (History)
1 user (show)

See Also:

broken GIF (78.62 KB, image/png)
2014-03-26 20:55 PDT, arkuka_reg
no flags Details
Patch for this problem (1.62 KB, application/octet-stream)
2014-04-14 01:51 PDT, arkuka_reg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description arkuka_reg 2014-03-26 20:55:52 PDT
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
Comment 1 arkuka_reg 2014-03-31 02:06:28 PDT
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.
Comment 2 arkuka_reg 2014-04-14 01:39:31 PDT
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
Comment 3 arkuka_reg 2014-04-14 01:51:26 PDT
Created attachment 229274 [details]
Patch for this problem

Patch for this problem. Only tested on Webkitgtk
Comment 4 Jeremy Zerfas 2015-08-09 09:54:26 PDT
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.