Closed Bug 522741 Opened 15 years ago Closed 13 years ago

Animated images display is rate-limited by download speed

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mikeharris19, Unassigned)

References

(
URL
)

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090806 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090806 Firefox/3.5.3

Firefox currently displays animated GIFs in excruciatingly slow frame-by-frame slow motion as the GIF in question loads.  It is only after the animated GIF file completely loads that the file completes a first loop and then runs further repetitive loops at a normal speed.

I'd argue that this is a functional difference, a fundamentally different display, from what any animated GIF creator intends.

I would completely agree with anyone's complaint that using animated GIFs to show short video clips, even ones of a few seconds, is a bit stupid nowadays.  That doesn't change the fact that Firefox users are going to nonetheless come across them, and come across them for time to come.

Reproducible: Always

Steps to Reproduce:
Locate an animated GIF which, on your Internet connection, is sizeable enough to take some time to load.  One source of such animated GIFs can usually be found by entering in "[gif]" into the search box of Reddit (http://www.reddit.com).  Click on a result.  Or, at the moment, this image fulfills those requirements:

http://img301.imageshack.us/img301/3439/bungeejumper.gif
Actual Results:  
The image moves slowly, frame by frame, as it first loads.  Once the file is completely loaded (which, depending on source, and on image size, can possibly take some time), the animation completes its first loop, if it hasn't already and (depending on if image.animation_mode has been changed) starts again displaying at normal speed.

Expected Results:  
What it should do might be a matter of some UI discussion.

As my own offering, I think that having the image be still, either on its first frame but lightly desaturated, or completely blacked out, and, either way, with a throbber as an overlay, would be enough to convey to the user that this image is loading -- and, given that most video sites utilize a similar methodology when their Flash videos are loading, it would be a metaphor that users would already be acclimated to and thus, for the most part, one they'd understand with little thought.

An alternate methodology might be play, stop and reload controls beneath the image.  I think that would be overkill, but I've seen it suggested in threads on this topic.



I think this item should not be deleted by, and is of significant importance to, the Firefox team because of two significant reasons that I can only imagine probably reflect core development values:

(1) Firefox is displaying this content in a way the usual non-technical end-user does not expect.

To them, that cute animated GIF that their friend sent them the link to, or e-mailed to them, is just "going slow" despite their fast Internet connection, and they're not likely to sink any time into it -- but if they do, they might try other browsers.  If they're Mac users, they'll see that even the most recent version of Safari has the same "bug" -- I can't speak to whether other Windows browsers have better methodologies of handling animated GIFs.

(2) Firefox is displaying this content in a way that the content's creators did not intend.

Quite simply, whomever places animated GIFs on the Web (and I do agree that with YouTube, Vimeo, etc., and the new VIDEO tag it's a fairly bad way to put even small video clips on the 'Net, but despite acknowledging that, I really don't think it's going anywhere) doesn't intend to have their clip displayed to ALL Firefox users in frame-by-frame slow motion.
[Also, despite my submission of this bug, I've never created an animated GIF in my life.  Just FYI. :-)]
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091015 Minefield/3.7a1pre

Takes indeed minutes to load. On every browser I tried, but Opera is the fastest.
Component: General → Graphics
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → thebes
Hardware: x86 → All
Version: unspecified → Trunk
I don't see this as bug, it's working by design.
Using such images with loadtimes in minutes is outside of the design of animated images
Component: Graphics → ImageLib
QA Contact: thebes → imagelib
There's a question of design and a question of real-life usage.  Should such images be animated GIFs?  No.  Do these files exist and will they continue to exist for the foreseeable future?  Yes.  I think that whether or not animated images with loadtimes in minutes _should_ exist or not, they _do_ exist, and won't be going away; accordingly, Firefox needs to handle them in a different manner that doesn't distort the video.
I agree this is sub-optimal (and FYI applies to APNG too), but fixing it correctly (which IMO is a video-style "buffer until we think we can play the whole image in real time," not just waiting until it's downloaded) involves some pretty significant code changes, and maybe even some integration with the <video> code. I can't see this being a priority, for me at least, ever, but I will very gladly help anyone who wants to do it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Firefox's Manner of Rendering Animated GIF Displays Content in Manner Unintended by (Any) Animated GIF's Creator → Animated images display is rate-limited by download speed
If you have a slow connection, you will notice that YouTube serves their videos the same way. Video starts playing before it's fully loaded. Most users like that.
How do you know they like it? All who I know press Pause when download speed is not enough, until the video loads completely.

At least, make it an about:config option and see how popular it is.
But do they press Pause when download speed is only slightly faster than playback speed? Not very likely. 

They just start watching the video, without waiting for complete download. 

I would expect the same for GIFs.
When playback is not affected there is no issue. This whole thing is about when download speed is slower and the playback IS affected by low download speed.
Yes, but if the proposed solution is to *always* wait for complete download, regardless of speed, it would negatively affect some people.

Just like if YouTube would suddenly require full download before playback starts, I bet they'll get a lot of complains.
Max, the YouTube analogy isn't even a proper comparison, because when an animated GIF starts up in Firefox, it starts up in slow motion.  Even if the idea is to start it up before it's fully loaded, showing it in painfully frame-by-frame slow motion until it's loaded is not what the original GIF author intends.  (And, yes, it's not the best way to show a sequence of moving pictures in this day and age -- but it's one of the oldest means of doing so and it shows no signs of going anywhere, so Firefox might as well display it correctly.)
Well, I think it's a pretty good comparison. 

With both GIFs and YouTube you have no problems when internet speed in good enough, but with both you get slow-motion/jerky playback over slower connection.

So I feel that waiting for full GIF download is very much like waiting for full YouTube download before starting a playback.
What about this: GIFs are played automatically, but once the browser finds that the next frame is not available yet, it stops animating that image until it is completely downloaded (optionally displaying progress animation over the image).
In reply to Stepin's comment on #12, I know of no YouTube video that plays in slow motion over a slower connection.  Jerky playback, yes, even on fast connections, but that's why you can pause it and let the whole thing load.

Quite simply, Firefox's present behavior does not display the "video" of the animated GIF the way it actually is -- as such, it's not being faithful to the original content and format of the image.  That's a problem.
Jerky, slow-motion... essentially the same thing.

Both means "it plays slower than original author intended".
With YouTube, I'm perfectly fine with whatever behavior they choose, because there is pause button. I see the download bar, I always know when to unpause and enjoy. 

With animated GIFs I'm annoyed all time while an image loads. Because I have no idea whether the download has been completed, I revisit the page every 30 seconds and get annoyed every time.

This is where your YouTube analogy breaks: YouTube does not annoy, animated GIFs do.
GIFs have been this way since the beginning, everywhere. If you want different behaviour surely you can just use a video. (GIFs are not videos)
It could be annoying, no argument here. The only question is how to solve it. 

I don't see any simple solutions, and complex ones (playback controls, throbbers) might require a lot of effort from developers. See comment #5.
In response to Stepin on #15, jerky and slow motion are definitely NOT the same thing -- they're entirely different behaviors.

Jerky YouTube playback are periods of normal playback speed interrupted by pauses as YouTube buffers.  Slow motion is frame-by-frame playback.

With the former, you're still seeing it the way its creator intended, just interrupted by pauses.  With the latter, you're not being shown it the way its creator intended.

Additionally, when YouTube is playing a video back, and there's slower bandwidth available (or whatever the problem is), you've got the option of pausing playback, letting the video load entirely, and watching it play back smoothly.  Not so with an animated GIF.

That's why I keep saying your comparison to a buffering YouTube video is fallacious.  The two situations aren't comparable.
In response to Mr. May on #17, there's theory and reality at play here.  Theory is, yes, a GIF is an image.  The problem is that animated GIFs are going nowhere -- they've been around since prior to the Internet, and were distributed on BBSs.  They'll continue into the future.  It'd be nice for Firefox to display them correctly, instead of with this "slow motion error" that it's had since *its* creation.
(In reply to comment #19)
> With the former, you're still seeing it the way its creator intended, just
> interrupted by pauses.  With the latter, you're not being shown it the way its
> creator intended.

I don't see the difference. Creator never intended the video to be interrupted by pauses.
(In reply to comment #21)
> I don't see the difference. Creator never intended the video to be interrupted
> by pauses.

There's the media itself, and then there's the playback mechanism.

With YouTube, you have the media (the video) funnelled through the player.  The player offers you the option of pausing it while it loads, letting you play the whole thing back unblemished, or of playing it at normal speed, in which case you will see "buffering" moments depending on your video, resolution and bandwidth.

With an animated GIF, you have the media being funnelled through the browser.  The only way that Firefox handles these images is by displaying it in slow motion while it loads, and then going at normal speed once the entire file is loaded.

If YouTube handled videos that way, the Internet would riot.

Yes, animated GIFs are archaic beings, but they've been around prior to the Internet and show utterly no sign of dying out.  It makes sense for Firefox's very longstanding bug in handling them to be repaired.  I'm really not sure why you're taking a stance opposing same.
Arguing about how close is the YouTube analogy is not helpful. Whatever way YouTube handles its videos does not change the fact that some animated images do have huge usability problem. If YouTube was not invented, we would still file this bug. If YouTube behaved exactly the opposite way, we would still file this bug. The analogy is useful when thinking about possible solutions, but no way it proves that gifs are ok.
Let's summarize. I see two major ways of handling GIF playback:

1. Overlay playback buttons: pause, progress bar, etc.

2. No overlays, browser tries to convert slow download speed 
into optimal playback as smartly as possible.

---

First method sounds nice. But playback controls could not fit into a very small GIF, and implementing overlay buttons could require a lot of effort from developers. They already said it's not a priority.

Second method could be:
a. show frames as soon as possible (slow playback - annoying)
b. wait for full download (long wait - annoying too)
c. compromise (download 10 frames, show 10 frames)

Historically all web content is displayed as soon as the first small portion of it is available, from simple HTML to JPEGs, instead of waiting for complete download. So suddenly switching from a. to b. would annoy a lot of people.

Maybe you would prefer c ?
See comment #13 for another option (say, 'd') — download 10 frames, play, if you can't download next frames fast enough for playback, pause and wait for full download.

Putting video playback controls on all animated images makes no sense to me, for sure. But it does not have to be all controls on all images or nothing. Having just a progress bar seems nice and sufficient for 'b' and 'd'.
With 'd' you'll have no idea whether it's stuck or not. 
With 'c' at least you'll have some idea of progress.
Well that's true. It needs throbber or progress bar.
Going back on my comment 5, I don't think I ever want to implement this. It's a lot of complexity for very little gain. This might change in the future, but for now, this is WONTFIX.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
That's a little sad. This needs to be a priority unlike many of the other things that get added into Firefox.
(In reply to Ryan from comment #29)
> That's a little sad. This needs to be a priority unlike many of the other
> things that get added into Firefox.

Not a matter of priority. The behaviour you propose actually existed in Firefox nightly for about two weeks (see bug 899861) and it was deemed a regression that needed to be fixed.
You need to log in before you can comment on or make changes to this bug.