Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!emory!gatech!mcnc!rti!bcw
From: bcw@rti.rti.org (Bruce Wright)
Newsgroups: comp.windows.ms
Subject: Re: How do I get large BMPs as desktops?
Summary: BMPs and GIFs
Keywords: BMP desktop
Message-ID: <1991Apr21.183828.9406@rti.rti.org>
Date: 21 Apr 91 18:38:28 GMT
References: <1991Apr13.125238.17769@uniwa.uwa.oz>
Organization: Research Triangle Institute, RTP, NC
Lines: 84

In article <1991Apr13.125238.17769@uniwa.uwa.oz>, andreww@uniwa.uwa.oz (Andrew John Williams) writes:
> 
> Hi- I have been converting gifs to .BMP files to use as wallpaper,
> hoping to have a large (1024x768x256c) file as a backdrop.
> Unfortunately, Windows seems to crash if I try to install a file larger
> than around 260k or so as a wallpaper. (257894 bytes workes, 262000
> doesnt). At first I thought it was the type of file, but it definitely
> seems to be the size. (I was trying OS2 .BMPs, and Windows compressed
> and uncompressed formats, to see which gave the smallest file size. Why
> did microsoft support an image compression standard so much worse than
> GIF???????).

I can't add much to what's already been said about your specific 
problem, but I can understand why Microsoft didn't support GIFs
in Windows.

The GIF format is computationally inefficient - it is designed to
be _small_, not _fast_.  It's the classic tradeoff of time vs space.
The idea of the GIF format was to reduce modem time for sending files
over a phone line, and to reduce disk space at both ends - not to be
a fast display format.

In a GUI environment, you don't want things to be slow - GUIs tend
to slow things down enough already.  So you certainly don't want the
_default_ compression format to be GIF - if you have any compression
format at all you want it real simple and _fast_.

Now why Microsoft didn't make GIF as an _option_ is another question;
perhaps they thought that the reduction in speed would give people 
a bad impression of Windows when they used GIFs as wallpaper, etc.
There are also some technical problems:  I have done a fair amount of
tinkering with low-level code to interpret GIF formats on various
sorts of hardware, and the format introduces some problems for a GUI
environment, of which the following list is a sample:

    1)	The GIF format does not have an easy way to find "scan line
	n" in an image without reading through the entire image until
	you find the beginning of that line - in other words, there's
	no way to index to a position, or to jump into the middle and
	find the proper reading frame and find the beginning of the
	desired line.  Even if you find the proper reading frame you
	still have no way to know what line number you're looking at
	without having interpreted the entire image preceeding it.

    2)	Interpreting GIF format is somewhat tricky;  many programs
	out there for doing this don't really do it properly (they
	may work with many GIF images but choke for some of them).
	You'd either have to build this code into every display and
	printer driver (imagine the possibilities for incompatible
	implementations given the plethora of problems with different
	GIF viewers that are out there), or you'd have to have the
	code to crack the GIF format embedded in Windows itself and
	feed a real BMP type structure to the device driver.  This
	could be done in pieces so that you didn't have to make a
	copy of the entire GIF (which would sorta negate the purpose
	of having a GIF format), but because of problem #1 and the
	general efficiency hit of dealing with GIFs in the first
	place it wouldn't be very nice.

    3)	Many GIFs have more than 16 colors, which is all that Windows
	supports for many purposes anyway - programs that want to use
	more must do quite a bit of palette manipulation.  Putting
	a 256-color .GIF as background would require a 256 color VGA
	driver (obviously), but it would also make it either impossible
	or ugly for another app to manipulate the 256-color palette
	for its own purposes (remember that the palette is a system-
	wide resource).  Many pictures with 16 colors or fewer don't
	take that much different space using GIF or a compressed BMP
	format (yes, I know there are pathological cases, especially
	with some huge files), so that the incentive to use GIF for 
	these simpler pictures isn't as big as it is for the more 
	complex pictures.  

I suspect it's one of those things that would be sort of nice to have,
but that you'd hardly ever use because of the penalties in performance 
and palette use that you'd have to live with.  Maybe Microsoft will
put it in, but (IMHO) it's sort of a marginal feature.  It might be more 
useful for them to make it easier to generate the compressed forms of
BMPs using the standard user-level software distributed with Windows,
and maybe distribute a GIF <-> compressed BMP converter so that anyone
who doesn't know about any of the PD/shareware converters out there
can still convert images.

						Bruce C. Wright