1511298 - Remove minimum frame delay from GIF89a files.

Status: RESOLVED WONTFIX

(Core :: Graphics: ImageLib, defect, P3)

Description

[Robert Ancell]

Attachment: animation-multi-image-zero-delay.gif

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

Steps to reproduce:

The GIF89a format is designed to composite multiple images together. This is useful to do things like:
- Use more than 256 colours by switching color tables while rendering
- Efficiently transmit animation by only sending small updates between frames

From section 8 (The Decoder) in the specification (https://www.w3.org/Graphics/GIF/spec-gif89a.txt): "The decoder has the following primary responsibilities." "Process each graphic in the Data Stream in sequence, without delays other than those specified in the control information.

Firefox adds a minimum frame delay of 0.1 second (bug 125137) between images in a GIF file, which causes short visual glitches which an image is being assembled. The reasons given seem to be:
- Handling broken GIFs in the wild
- Matching the behaviour of other browsers

It was proposed some years ago (bug 890743) to not do this delay when the GIF doesn't loop, but then that was reverted in bug 1126330.

I've attached a test case that shows this.


Actual results:

The animation shows 7 frames, with red pixels flashing while rendering.


Expected results:

The animation should show only four frames, with no red visible (total time 2s).

Comment 1

[Robert Ancell]

Analysing the two cases in the bugs that stopped the frame delay being removed:

1. http://gassend.net/spaceelevator/breaks/break0.gif

This is a GIF87a file, and that specification did not have the Graphic Control Extension (which sets the delay). So I think it's reasonable to have a default delay in these files.

2. https://i.imgur.com/krYrx02.gif

This is a GIF89a file which has Graphic Control Extensions but they're all set to zero. This is probably a case where a heuristic could be applied if necessary.

Are there any other cases that anyone knows of where GIFs are broken?

Comment 2

[Robert Ancell]

See related bug 1511290 about the delays being applied to multiple images. Both these bugs have come out of developing a GIF test suite (https://github.com/robert-ancell/pygif/tree/master/test-suite).

Comment 3

[Robert Ancell]

Attachment: Animation that flashes red - the red parts should have zero delay.

This is a larger image showing the issue

Comment 4

[Robert Ancell]

The above image was generated with:

#!/usr/bin/python

import gif

width = 40
height = 40

writer = gif.Writer (open ('animate-min-delay.gif', 'wb'))
writer.write_header ()
writer.write_screen_descriptor (2*width, 2*height, has_color_table = True, depth = 2)
writer.write_color_table ([(0, 0, 0), (255, 255, 255), (255, 0, 0), (0, 255, 0)], 2)
writer.write_netscape_extension (loop_count = 0)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 50)
writer.write_image (2*width, 2*height, 2, ([ 1 ] * width + [ 0 ] * width) * height + [ 0 ] * (2 * width) * height)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 0)
writer.write_image (width, height, 2, [ 2 ] * width * height, width, 0)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 50)
writer.write_image (width, height, 2, [ 1 ] * width * height, width, 0)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 0)
writer.write_image (width, height, 2, [ 2 ] * width * height, width, height)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 50)
writer.write_image (width, height, 2, [ 1 ] * width * height, width, height)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 0)
writer.write_image (width, height, 2, [ 2 ] * width * height, 0, height)
writer.write_graphic_control_extension (gif.DisposalMethod.KEEP, delay_time = 50)
writer.write_image (width, height, 2, [ 1 ] * width * height, 0, height)
writer.write_trailer ()

Comment 5

[Robert Ancell]

Attachment: What the animation should look like

Comment 6

[Robert Ancell]

Attachment: A test case showing a 256x256 image that is animated loading (it should be instant)

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

I'm hesitant to change the behaviour of this now given it has worked this way for so long. Chrome renders the images the exact same way as Firefox for also good reasons, so we may be setting ourselves up for a webcompat nightmare.

https://cs.chromium.org/chromium/src/third_party/blink/renderer/platform/graphics/deferred_image_decoder.cc?l=351&rcl=e15f3c2e15ee7570159406526444fa1ffb35150f