Why not use animated GIFs as a lightweight alternative to AVIs in the animation common control?


Commenter Vilx- wondered why animated GIFs weren't used as the animation format for the shell animation common control. After all, "they are even more lightweight than AVIs."

Animated GIFs are certainly more lightweight than general AVIs, since AVI is just a container format, so decoding a general AVI means decoding any encoding format invented now or in the future. On the other hand, the shell common control imposed enough limits on the type of AVIs it could handle to the point where what was left was extremely lightweight, certainly much more lightweight than an animated GIF.

Think about it: To use an animated GIF, you need a GIF decoder. And a GIF decoder is already significantly larger (both in terms of code and memory) than the RLE-8 decoder. Also significantly more complicated, and therefore significantly more likely to have bugs. Whereas RLE-8 is so simple there isn't much that can go wrong, and the RLE-8 decoder had been around since Windows 3.0, so it was already a known quantity. All you have to do to invoke the RLE-8 decoder is call Set­DI­Bits­To­Device. One line of code is hard to beat.

Windows 95 did not come with a GIF decoder. Remember, Internet Explorer 1.0 did not come with Windows 95; it was part of the Plus! pack. As I recall, at the time Windows 95 released to manufacturing, the Plus! pack was still under development. (And at the time the animation common control was being designed, Internet Explorer didn't exist. Heck, Mosaic didn't exist!) Plus the fact that the common controls were available in both 16-bit and 32-bit versions—in fact it was the 16-bit versions that were written first since Windows 95 didn't have good Win32 support at the start of the project. More accurately, Windows 95 didn't have any Win32 support at the start of the project.

So I'm kind of amused by the description of GIF as a lightweight animation encoding algorithm. Compared to RLE, the GIF format weighs a ton!

Comments (27)
  1. Gabe says:

    And here I thought the answer was going to be as simple as the animated GIF standard hadn't been invented by Netscape until after Win95 was released. While the GIF standard existed, the animation extension only came out with Netscape 2.0 in 1996.

  2. Vilx- says:

    Hey Raymond mentioned me in his blog! I'm famous!!! Yay! I'm going to start selling tickets to people who want to touch me!

  3. Daniel says:

    Not sure if this was a factor, but 1993 was when Unisys became aware that the GIF format (developed in 1987) used the LZW compression, and entered into licensing negotiations with CompuServe. So the GIF format was controversial at the time (in 95 the PNG format was developed as an intended replacement). Source: Wikipedia

  4. Vilx- says:

    Umm… something happened to my first comment (before the Yay). Maybe it's still in moderation, maybe not… I'll re-post just to be sure:

    Ahh, just goes to show what I know. :) All valid points.

    Although the animation extension was around since 1989 already. I know – I implemented GIF reader in .NET! :) True though, the spec says in Appendix D: "Animation – The Graphics Interchange Format is not intended as a platform for animation, even though it can be done in a limited way." Netscape just added the looping extension. Otherwise the animation would run only once.

    But I hadn't thought/known that the RLE8 AVI was even simpler, or that the code was already in Windows 3.0 (meaning that GIF was just born and not very popular). The gut instinct was AVI == complexity; GIF == simplicity.

  5. Dan says:

    Gabe, i guess the modern gif format – gif89a – got 89 ins name for a reason.

  6. James Schend says:

    IIRC, the other non-animated GIF variant is gif87. But without Netscape's looping feature, animation in a GIF is pretty useless, it seems to me.

  7. RichB says:

    @gabe:

    There is conflicting information about when NN2 came out. The following page says NN2 with animated gif support came on September 18, 1995.

    en.wikipedia.org/…/Netscape_(web_browser)

    I certainly remember animated gifs in a web browser in early 1995, so perhaps that was a beta of NN2?

  8. Miff says:

    The source of those comments is more then likely people associating AVI with something like MJPEG or XVID.

  9. 640k says:

    AVI support is included in video for windows, which was released years ahead of any 32-bit ms os. WfV is a pluggable architecture, with support for ANY codec. You could implement a gif codec as a VfW codec.

  10. MikeCaron says:

    640k: Yes, that is certainly a good way to use GIFs as a lightweight animation! Just embed a movie player!

  11. Raphael says:

    @640k

    Video for Windows: November 1992

    Windows NT 3.1: July 1993

    And knowing is half the battle!

  12. Silly says:

    ASCII: The best animation format ever!!

    http://www.asciimation.co.nz/

  13. Matt says:

    "(And at the time the animation common control was being designed, Internet Explorer didn't exist. Heck, Mosaic didn't exist!"

    Mosaic for Windows came out in 1993.

    [I don't know the exact date, but the animation common control was designed around 1990ish I think. (Count the number of hedge words.) -Raymond]
  14. cheong00 says:

    Back in the Win3.X days, the only animation formats that I know are AVI and FLIC. In my secondary school, one of my friend possess God like animated 3D graphics skill (in the eyes of me, of course) and chained many 486 machines in computer room to render movies for competition.

  15. Gabe says:

    Prior to Netscape's use of GIFs for animation, GIFs were not thought of as a means of conveying animation. Had Netscape not chosen GIF as its animation format in 1995 (or '96, or '94), the question would have never been asked because nobody would think of GIF as an animation format.

    The extensions added by CompuServe in 1989 were not intended to facilitate animation. They are capable of describing animation, but it seems the Graphic Control Extension (which allows you to specify a delay) was intended for something more like specifying PowerPoint-like slideshow presentations. I say this because it specifies the delay in increments of 0.01 sec (rather than ms or fps), it allows you to specify that the previous contents be displayed after a frame is shown, and there is a flag to indicate that user interaction (like a key press or mouse click) is called for. They also added an extension for showing text.

    I mean, sure, you could use a GIF for animation, but at that point what format *can't* you use for animation? You may as well have asked why they didn't use TIFF, for example. It already has multiple image support and RLE compression (though I understand it's the Mac format).

  16. ender says:

    @Gabe: The problem with TIFF is that it's almost like AVI – it supports a ton of different encodings, and there's no guarantee that the TIFF you have will open in every program that claims to support TIFF (or that such program will be able to create a TIFF file that a different program will be able to open).

    (Also, what idiots wrote this blog software – having to post everything twice is not good UX.)

  17. Neil says:

    Presumably I failed to understand Raymond, or maybe Windows 95 really does owe nothing to Win32s or WinNT.

  18. Crescens2k says:

    @Neil:

    Win95 should owe a lot to both. The Win32 API which was used is what was designed for Windows NT. Win32s was an addon for Windows 3.x that allowed it to run in proper 32 bit mode.

    What Raymond really said, was at the start of the Windows 95 project, the initial builds were 16 bit. 32 bit support was built into it later. It was at that point where they used the knowledge gained from Win32s and the API from Windows NT to get the 32 bit support in Windows 95.

    I'm sure if you look at it's architecture, you would find a lot of similarities between Windows 95 and Windows 3.11 with Win32s.

  19. laonianren says:

    Animated GIF is a lot more bloaty than it needs to be.  It seems to have been designed to allow the LZW dictionary to be reused across frames but later specs preclude this, presumably because nobody implemented it properly.

    And even if Internet Explorer had existed in the Win95 timeframe, you wouldn't have wanted to use the animated GIF support: it's dreadful.  When it displays a frame it seems to be decoding the entire GIF as far as that frame, so playback becomes progressively slower.

  20. Waleri says:

    You should either decode entire GIF or at least keep last decoded frame, because frames (can) be stored as "changes" from from previous frame by mean of using smaller region, i.e. new frame should be placed ontop of old one, so yes, if you need to access last frame you may have to decode all previous frames.

  21. mh says:

    You should either decode entire GIF or at least keep last decoded frame, because frames (can) be stored as "changes" from from previous frame by mean of using smaller region, i.e. new frame should be placed ontop of old one, so yes, if you need to access last frame you may have to decode all previous frames.

    You'd have to keep multiple frames in memory though, wouldn't you?  And at least two of them (current and previous) could never be swapped out?  Something you wouldn't think twice about nowadays of course, but back then…

  22. laonianren says:

    @mh:

    You only have to keep two frames in memory: the one displayed on the screen and the one you're updating.  When you want to display the next frame you load the next delta from the gif file (which is often much smaller than a frame) and calculate the new frame in the off-screen copy.

    If you decode the gif from the beginning of the file for each frame (as IE seems to) you need just as much memory for the decoding AND you need to re-read much of the gif file (or keep the whole thing in memory).  You'll often need to do this ten or twenty times a second, in which case the gif data will never be paged out.  So you actually use more memory.

  23. John Topley says:

    @Crescens2k:

    Win32s was an add-on for Windows 3.x that allowed it to run *some* 32-bit software by providing a subset of the Win32 API as implemented in early versions of Windows NT. The "s" in Win32s actually stood for "subset".

  24. 640k says:

    @John Topley

    win32s was more than a strict subset, it was a completely different enviroment.

    Proof: Some win32s programs (freecell) doesn't work in real 32-bit windows os.

  25. ender says:

    @640k: I've got Windows 3.1 with Win32s installed in DOSBox, and Freecell that ships with Win32s works just fine on my Windows 7 x64 (it also works in Windows 95 in VMWare).

  26. Yuhong Bao says:

    "Plus the fact that the common controls were available in both 16-bit and 32-bit versions—in fact it was the 16-bit versions that were written first since Windows 95 didn't have good Win32 support at the start of the project."

    BTW, why was the 16-bit COMMCTRL and new functions in 16-bit KRNL386/USER/GDI in Win9x never officially documented, at least in release documentation?

  27. Klimax says:

    @Yuhong Bao: My guess is they wanted every one out of 16-bit giving every incetive to move. Provide and documetn new api in 16-bít and they just stay there…

    (We are sometimes quite lazy ;) )

Comments are closed.

Skip to main content