Closed Bug 149205 Opened 23 years ago Closed 14 years ago

Truecolor gif loads very slowly

Categories

(Core :: Graphics: ImageLib, defect)

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

Tracking

()

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: netdragon, Unassigned)

References

(
URL
)

Details

Attachments

(4 files)

Attachment of the image
864.58 KB, image/gif
Details
Another deep-color GIF, this one shows all colors.
180.24 KB, image/gif
Details
General multi-image GIF, w/o truecolor
20.70 KB, image/gif
Details
Tentative patch to show all how can trick truecolors gif to display more quickly
8.46 KB, patch
Details | Diff | Splinter Review
On http://openil.sourceforge.net/?id=34, I saw mention of a truecolor gif. http://phil.ipal.org/tc.html says it confirms to the GIF89A standard but that truecolor gifs weren't used because of the hardware limitations of the time, and therefore people didn't even know they were possible. Expected Result: Loads as quickly as it does in Photoshop. Result: Loads very slowly 5/30/2002 trunk build I will attach a copy of the image (http://phil.ipal.org/bike-d.gif) in case the site goes down.
Attached image Attachment of the image —
Here is the truecolor GIF image. Here are time comparisons render off my disk: Mozilla: 77 seconds Photoshop: 6 seconds This could also be an alert that GIF rendering in general isn't well optimized.
I just realized how this works. GIFs allow multiple blocks. This is how animated GIFs are made. Therefore, there were many blocks made, each with only 256 colors. That is why the image appears in chunks. I'm not sure, though, why Mozilla is so slow on each chunk, but I assume some part of the GIF code is creating a bottleneck. This might possibly affect other GIF images?
It's an interesting concept (true-color gifs), however, the reason it's slow on Mozilla is because we have a minumum 100ms delay on each frame. Mozilla has been doing this for gifs with 0ms frame delays since Apr 13 2001. The reason being it throttled the CPU (especially if it was a looping gif) I wouldn't mind seeing the 100ms delay removed for frames with 0ms delays when the gif is not a looping gif. Or better yet, the frames should be combined when they have 0ms delay.
FYI - on my machine(win95) this image takes an equally long time to load in Opera 6.03, and about five/six times longer to load in IE5.5. IE gets totally bogged down by this image, scrolling and resizing are horribly slow. Moz(rc3) and Opera are about equal, with Opera being a bit smoother on scrolling.
Dylan: I'm sure you are aware of this, but I'll say it anyway. Bugs in other applications don't give us an excuse to leave one in ours. Arron: Do you know, or have an idea of the specific bug on which the throttling of the CPU was reported? Perhaps we can file a new bug to come up with a better way to handle 0ms delays and set it as a blocker for this bug. I'd like to know the specifics of that, though, beforehand.
Target Milestone: --- → Future
This is a terrible hack. "Neat" maybe, but certainly not something that Mozilla should endeavour to support. I couldn't get IE to load it at all, Moz did take along time, NS4 took less time. As the page noted by the reporter states: "While using more than 256 colors in GIF is in most cases a bad practice, and should be limited to certain technical cases where extreme size can be tolerated, a statement that the GIF image file format is limited to 256 colors is simply false." This is true, by using the fact that each frame on a GIF89a can also hold a separate color palette, and can be independently positioned. As such, each frame is still 8 bits, and so each section of a "truecolor" GIF89a will be 8 bits. The only way to ensure that a large picture done in this method is truly truecolor, one must make each frame so small as so not to encompas more than 256 pixels, or 16 pixels square. With the advent of the PNG format, the massive overhead (size and CPU), this format is truly worthless. While it may somehow pass a spec validator (just as would much XHTML or HTML4.01), it is still in actual violation of the spec (as is much XHTML/HTML4.01 etc, just ask Hixie). Officially, I nominate this bug for WONTFIX. As HEndikins said on #mozillazine, "<Hendikins> that GIF is like Microsoft "HTML"... it rapes and tortures the standards."
Jesus_X: For a bit of devil's advocacy, I managed to get this to load in IE6. Also, remember what ArronM said in comment #3... ... >Mozilla is because we have a minumum 100ms delay on each frame. Mozilla has >been doing this for gifs with 0ms frame delays since Apr 13 2001. The reason >being it throttled the CPU (especially if it was a looping gif) >I wouldn't mind seeing the 100ms delay removed for frames with 0ms delays when >the gif is not a looping gif. Or better yet, the frames should be combined when >they have 0ms delay. Obviously, this bug brings up an issue that we have an innapropriate minimum delay on Gifs. If we can find some way around throttling the CPU with the images, then this bug would be fixed in the process... I vote against WONTFIX since this bug actually provides another example of the problem with the 100ms limit. We should work towards a solution of that issue. This might actually provide another useful test of that solution.
Additionally, I have found images like this can crash many applications, and suck up a LOT of memory. On a 700MHz Athlon with 192MB RAM (sure it's not top of the line, but it's still adamn good box :), Loading this image in Photoshop sucked up ALL of the available RAM, swap file space, and Photoshop had to be terminated after several minutes of thrashing about in pain. At best this should be viewed as a bug in the GIF89a spec. I still heartily recommend against support.
I've attached another deep-color GIF. This one might be easier to test with. On Mozilla 1.3 on Windows 2000, neither of these images work. Mozilla just shows the upper-left corner of the image and stops. Wouldn't it be easier to convert the GIF into some other format, than trying to render it on the fly every time? I'm also going to vote against WONTFIX, because the point of Mozilla if it's not going to support standards?
The delay (or slow performance) is caused by the minimal delay of 10msecs between each frame. You can see this happening in the drawing of each tile separately. In the gif file the delay is set to 0, to make it fast. But, generally animations in browsers such as IE, firefox, opera always apply a minimal delay (the 10msecs)... A trick would be to detect these 24bit truecolor gif images, and then not to apply the minimal delay. One way of detecting is that the frame do not overlap (which is not true for normal animated gifs).
Can't we just not apply the minimum delay at the end of each loop in an endless GIF instead of between each frame?
Strictly speaking, multi-image GIFs with a timeout of 0ms can't be called animations, and therefore should be handled differently. Multiple images in the same GIF file were included in the specification right from the beginning, in GIF87a. Of course, this was not done in order to facilitate later workarounds or hacks for truecolor GIFs (which I doubt anybody uses in practice), but to seperate areas of the whole image (called "screen" in the spec) that do not belong to each other logically. It explicitly says what a decoder should do when there are multiple images: (http://netghost.narod.ru/gff/vendspec/gif/gif87a.txt) Appendix D - Multiple Image Processing Since a GIF data stream can contain multiple images, it is necessary to describe processing and display of such a file. Because the image descriptor allows for placement of the image within the logical screen, it is possible to define a sequence of images that may each be a partial screen, but in total fill the entire screen. The guidelines for handling the multiple image situation are: 1. There is no pause between images. Each is processed immediately as seen by the decoder. 2. (...) Then, later, GIF89a added the Graphic Control Extension. It allows to specify (among other things like transparency) a delay time a decoder should wait before processing the next image. That's how animated GIFs are implemented in the first place. Again, the spec clearly states that this delay is optional: (http://www.w3.org/Graphics/GIF/spec-gif89a.txt) vii) Delay Time - If not 0, this field specifies the number of hundredths (1/100) of a second to wait before continuing with the processing of the Data Stream. (...) Of course, people should not be encouraged to (ab)use this feature for "dirty" workarounds in order to create truecolor GIFs. Yet this is certainly not a reason to not implement the spec correctly. Education is good, but strict standards compliance is more important, for there are sometimes legitimate reasons to use even the most exotic feature. (Just have a look at the attachment: The timestamps on the right are implemented as seperate images in order to make them easy to insert, and to keep the main image small, thus keeping the processing time required for rebuilding it low.) As to what #10 said about overlapping images: I don't think this is a good idea, as images may infact overlap and still have no timeout. This was also provided for in GIF87a, as the second point of the above list: 2. Each image explicitly overwrites any image already on the screen inside of its window. The best and most reliable method is to just comply with the spec and use the delay value (or assume 0 if none specified).
I agree fully on following specs and standards. However, there are so many 'faulty' GIF images around, and so many bugs reported about these being 'too fast' in mozilla (or causing 100% CPU load, because they animate at full speed), we have to find a solution for handling those 'faulty' but sort of 'de facto standard' animation using '0' as timeout value... See other bugs on animated gifs for lengthy discussions on this. A good way to detect correct from faulty usage (0 delay for multiframe composition like you described, or 0 delay for animations, which is generally then upped to 100mseconds) is required to solve this bug. So, anyone who can find this way, please report immediatly!
We could treat everything with a loop count > 1 or 0 (=infinite) as an animation, and everything else as multi-frame. That way, we can keep the old behaviour for looping animations. What would change is the behaviour for non-looping animations with a faulty delay value. Those would be displayed wrongly, but CPU usage wouldn't normally be a problem because it doesn't go on forever. Still, there could be occasions where each frame of an animation consits of several images itself. For this case, maybe we could look if any image in the file has a valid delay value. If so, treat it correctly, otherwise, up it to 100ms.
This patch follows comment #14 assume that when LoopCount is not specified, it is really a 'non-animated' multiframe image, and if so, keeps delay at zero. For non-zero delays in all cases it is thresholded to 100msecs for values below 10msecs (see the comments in gfx/src/shared/gfxImageFrame.cpp). Also make imgContainerGif display directly (when possible) the next frame when the timeout/delay is zero. (note the 'goto loop' to be replaced by a nice 'do/while' off course...). This makes loading of multiframe/non-animated images much quicker, and still display incrementally when needed. For such images from local filestorage, the whole image is displayed immediately. For normal animated images this still behaves at 'expected'. Note that in the original code there are two locations where the Delay factor is adjusted. Which of them is correct?
Comment on attachment 192935 [details] [diff] [review] Tentative patch to show all how can trick truecolors gif to display more quickly Note: if (aDelayTimeout > 0 && aDelayTimeout < 10) should have been: if (aDelayTimeout > 0 && aDelayTimeout <= 10) (and 10 should may be either 50 or 100...)
We support Truecolor PNGs -- use those. In practice I don't think anyone actually uses multiframe non-animated GIFs on the web. Trying to fix this seems like we're only going to cause animations to not work as expected...
I heard hyatt fixed the 10msec issue in Webkit's implementation of libpr0n. Out of curiousity, aren't there better alternatives (such as yielding back to the OS) to handle CPU throttling than a 10msec timeout? We're not implementing the standard properly and this image is more of a testcase of that rather than a useful implementation of the .gif format. Besides, 10msec is not really a guaranteed way to prevent cpu throttling.
Assignee: pavlov → nobody
QA Contact: tpreston → imagelib
Still reproducible in Firefox 10.0a1 and in Chrome 14. As was discussed above, this is just how GIF works.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
Meh, it's a gray area but I guess 'invalid' is more accurate.
Resolution: WORKSFORME → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: