Closed Bug 1511298 Opened 2 years ago Closed 6 months ago

Remove minimum frame delay from GIF89a files.

Categories

(Core :: ImageLib, defect, P3)

63 Branch
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: robert.ancell, Unassigned)

Details

Attachments

(3 files, 1 obsolete file)

Attached image animation-multi-image-zero-delay.gif (obsolete) —
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).
Component: Untriaged → ImageLib
Product: Firefox → Core
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?
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).
This is a larger image showing the issue
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 ()
Attachment #9028868 - Attachment is obsolete: true
Attachment #9028870 - Attachment description: animate-min-delay.gif → Animation that flashes red - the red parts should have zero delay.
Flags: needinfo?(aosmond)
Priority: -- → P3

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

Status: UNCONFIRMED → RESOLVED
Closed: 6 months ago
Flags: needinfo?(aosmond)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.