Truecolor gif loads very slowly




17 years ago
7 years ago


(Reporter: netdragon, Unassigned)



Firefox Tracking Flags

(Not tracked)




(4 attachments)



17 years ago
On, I saw mention of a truecolor gif. 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 ( in case the
site goes down.

Comment 1

17 years ago
Created attachment 86361 [details]
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.

Comment 2

17 years ago
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?

Comment 3

17 years ago
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.

Comment 4

17 years ago
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. 

Comment 5

17 years ago
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.


17 years ago
Target Milestone: --- → Future

Comment 6

16 years ago
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

Comment 7

16 years ago
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.

Comment 8

16 years ago
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.

Comment 9

16 years ago
Created attachment 125233 [details]
Another deep-color GIF, this one shows all colors.

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?

Comment 10

14 years ago
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

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).

Comment 11

14 years ago
Can't we just not apply the minimum delay at the end of each loop in an endless
GIF instead of between each frame?

Comment 12

14 years ago
Created attachment 191003 [details]
General multi-image GIF, w/o truecolor

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:

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:

	    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).

Comment 13

14 years ago
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!

Comment 14

14 years ago
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

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.

Comment 15

14 years ago
Created attachment 192935 [details] [diff] [review]
Tentative patch to show all how can trick truecolors gif to display more quickly

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 16

14 years ago
Comment on attachment 192935 [details] [diff] [review]
Tentative patch to show all how can trick truecolors gif to display more quickly

  if (aDelayTimeout > 0 && aDelayTimeout < 10)
should have been:
  if (aDelayTimeout > 0 && aDelayTimeout <= 10)
(and 10 should may be either 50 or 100...)

Comment 17

14 years ago
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...

Comment 18

13 years ago
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.


12 years ago
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.
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Meh, it's a gray area but I guess 'invalid' is more accurate.
You need to log in before you can comment on or make changes to this bug.