Tiny gifs: not a good idea. [Archive]

thudfactor

06-06-2002, 11:03 AM

I thought I'd bring this up since I just ran into it again at work. A lot of web designers, trying to squeeze every last byte out of a graphic they're putting on the web pages, are hoisting themselves on their own efficiency petard.

It works like this: you need a background that's a small pattern -- like the bar at the top of this page (http://www.aaas.org). Since "people don't like to wait for large backgrounds to load," you make this image 1 pixel wide -- so it's as small as possible -- and then let the browser tile it.

The problem: now the image is so small it has to be tiled repeatedly. Slow computers are going to take forever to display it. In fact, on an old 586 or x68040 you might even be able to watch the screen draw (and redraw...every time the image needs to be displayed again...).

Even on fast machines, you're forcing it to do needless work.

I took the background image in question, which is a 1x62 pixel graphic provided by a design firm, and created a 300x62 pixel version of the same thing. Now, three copies of the image will cover an 800 pixel screen -- instead of 800 copies. That's a dramatic drop in resources required by the browser. 1x62 file size: 181 bytes.

<self-promotion>
For more detailed discussion of why tiny GIFs must die, you can read my tutorial "Tiny GIFs must die!" at http://www.thudfactor.com/writing.php?show=14
</self-promotion>

--
John, master of the trivial.

dank

06-06-2002, 11:43 AM

I would think something is seriously wrong with your computer/browser for you to see any detrimental effects of single pixel gif stretching. I use that method all the time and my old Pentium 133 with 16 meg RAM that can barely load a browser (no exaggeration) has no problem displaying such pages.

Dan

edit: One thing to avoid is stretching partially transparent gifs. Not all browsers support it, resulting in a blank graphic all the way across the stretched section. Not pretty.

thudfactor

06-06-2002, 01:16 PM

Stretching works quite differently from tiling. I've not seen any adverse effects from stretching any gifs for quite some time -- I think early browsers tended to do funny things if you stretched with a percentage, however.

I'm speaking more to the <body background="1x1pixel.gif"> kinds of things, where someone is tiling an image over and over.

PaulKroll

06-06-2002, 01:20 PM

That's true, but stretching and tiling are two different things: stretching can be done with an operation that doesn't require the browser to make thousands of memory allocations. Tiling, well, does. Worse, some browsers treat (or treated, as I'm not sure if any current browser does this) each graphic as a windows resouce... i.e., as a window... you can imagine the pain and suffering from the overhead of opening a couple thousand tiny windows. :)

EDIT: Leave it to a cartoon rhino to STEP ON MY LINES... :)

thudfactor

06-06-2002, 01:23 PM

Oh, I just noticed that I left a detail out of my original post. The 1x62 pixel image was approximately 186 bytes, whereas the 300x62px image was approximately 280 bytes. So it's not that significant a performance hit -- and it's drastically reducing the memory required. (800 x 186 = 145k, 3 x 280 = .8 k)

dank

06-06-2002, 01:50 PM

Doh, I realized just before checking back that you were talking about tiling, not stretching, and now it's too late to edit my post and cover my tracks... :)

I've used tiled backgrounds (usually 20x20) on a few sites without any adverse effects...

Dan

thudfactor

06-06-2002, 02:23 PM

Even 20x20 is better than 1x1 -- 400 times better, in fact. :-) Occasionally I still see people set their background color by making a 1x1 pixel gif set to the color they want and then set as the background.

Hell, everyone needs a pet peeve. It's just that mine are more obscure than most. :-)

koala

06-06-2002, 07:31 PM

I must say that I always use tiny 1 or 2 pixel high gifs for backgrounds where applicable, and have never noticed a load time problem.

I have put up a couple of examples here (http://www.koalas.net/background/index.html) so you can test the load times for yourself :)

Simon

thudfactor

06-06-2002, 07:45 PM

You won't notice a load time problem unless you're on a slow computer - - anything slower than 200Mhz or so, I think.

What's the point? Well, what's the point of making a 1 or 2 pixel gif? So it downloads fast! But you're swelling the size of the graphic in memory on the client machine, forcing thousands, possibly millions of extra operations on the client machine, and for what? A savings of half a kilobyte.

If you're that concerned over half a kiliobyte of file size, it seems to me that you should be equally, if not more, concerned over the extra operations & computer memory you're hogging by making such a tiny graphic your background.

Terra

06-06-2002, 08:29 PM

Tiling, well, does. Worse, some browsers treat (or treated, as I'm not sure if any current browser does this) each graphic as a windows resouce...
Curious...

It would seem the browser programmers would take this into account and optimize it away... I would be shocked at the ineptitude for a browser to assign resource handles to each repeated tile instance...

Has anyone peeked inside Mozilla to see how a tile is handled?

--
Terra
--nothing much surprises me anymore--
FutureQuest

janderk

06-07-2002, 04:36 AM

Originally posted by Terra:
It would seem the browser programmers would take this into account and optimize it away... I would be shocked at the ineptitude for a browser to assign resource handles to each repeated tile instance...You are right. Tiling is generally done by copying 1 bitmap multiple times to a canvas. Allocating multiple handles does not even make a tiny bit of sense. No need to look at any source code for that.

But it is true that the optimal tiling image size is larger than a 1x1 pixel. I always take something like 30x30.

Jan Derk

BenV

06-07-2002, 07:31 AM

Originally posted by janderk:
You are right. Tiling is generally done by copying 1 bitmap multiple times to a canvas. Allocating multiple handles does not even make a tiny bit of sense. No need to look at any source code for that.
Not sure if you are disagreeing with Thudfactor, but I don't think his beef was with resource usage, but with a slow computer having to redraw the bitmap 4000 number of times (as opposed to 200) and the extra processor power required to do so.
---
BenV

janderk

06-07-2002, 08:01 AM

Originally posted by BenV:
Not sure if you are disagreeing with Thudfactor, but I don't think his beef was with resource usage, but with a slow computer having to redraw the bitmap 4000 number of times (as opposed to 200) and the extra processor power required to do so.I don't think that Thudfactor was the one stating that. Paul said that some old browsers used a windows resource for each image. Yes that would slow down performance, but it would make absolutely no sense to do that.

Drawing a small bitmap a few thousand times on a canvas might sound impressive but is just some memory copying and almost trivial for any (old or new) processor. That's why I wouldn't mind too much about the size of the background images. But I do agree with Thudfactor's original idea that if you are picky, it's better to use a 20x20 image than a 1x1 one. But IMHO there are a thousands things more important when designing web pages.

Where I do disagree is here:
The 1x62 pixel image was approximately 186 bytes, whereas the 300x62px image was approximately 280 bytes. So it's not that significant a performance hit -- and it's drastically reducing the memory required. (800 x 186 = 145k, 3 x 280 = .8 k)Larger images will not lead to lower memory usage as all images are handled uncompressed in memory when drawing on a canvas.

Jan Derk

thudfactor

06-07-2002, 09:08 AM

Drawing a small bitmap a few thousand times on a canvas might sound impressive but is just some memory copying and almost trivial for any (old or new) processor. Depends on your definition of old, I suppose. I have had recent complaints about this from people on sites that have a lot of traffic. When I originially discovered this problem (which would have been in 1996) I actually got to see it for myself on a reasonably new 586 -- a 1x1 pixel white dot I was using as a background (to overcome early netscape problems) tiled so slowly on that computer that it took a full minute to render the page at a high screen resolution. I doubt any computer made after 1996 would have a problem, though.

Larger images will not lead to lower memory usage as all images are handled uncompressed in memory when drawing on a canvas.

Ah. OK, I'll conceed that point, then.

As far as there being "bigger" problems are concerned -- nice pun. ;)

kitchin

06-07-2002, 12:06 PM

I use 30x10 for some reason. I remember some old browser would crash on certain extreme stretches. Divide by zero if I recall, on either reducing to 1 pixel high or expanding from 1 pixel high.

Matt

06-07-2002, 04:12 PM

I doubt any computer made after 1996 would have a problem, though.

I would be interested in a bit more research on this. I use 2x2 pixel backgrounds and have never noticed such a problem (even on a 166Mhz 586 @ 1024 x 768) using IE5 under Windows 98. Perhaps it is limited to certain browsers and/ or versions? If this behavior is due to browser inefficencies in older browsers (pre 4.x), it might not be a major concern as most pages aren't designed for these browsers anyway. From a theoretical standpoint, however, a slight speed hit might be more apparent if a visitor is playing MP3's in the background while running other software in addition to a browser... thus leaving few spare clock cycles for rendering a 1x1 pixel background.

My biggest problem on a 166Mhz 586 is viewing flash movies... they usually don't play at the proper speed, which tends to make some flash promo's look a little silly.

Matt
- On a 25Mhz Mac LC475 EVERYTHING renders slow :P

agallager

06-14-2002, 10:41 AM

When I looked at the AAAS bar, the background is just a flat color (6666CC) not a pattern. Why not just fill the banner cell with the right color, instead of tiling background gifs (whether small or large)? Maybe I'm missing something...
:)

kitchin

06-14-2002, 12:18 PM

Background colors do not always render as exactly the right color, I've found.

PaulKroll

06-14-2002, 12:26 PM

Background colors do not always render as exactly the right color
Odd. If a computer is set to 24/32 bit (or "millions of colors" for the Mac last I saw), that should never happen. If it does, something's wrong.

Conversely, nothing prevents a computer set to 16 bit color ("thousands of colors") from choosing the wrong (but close) colors for the background gif instead of the wrong colors for the background table color, so you might find it's just as big a problem for your users with or without the tiled gifs.

Matt

06-14-2002, 12:57 PM

I agree with Kitchin on this point: Background colors do not always render as exactly the right color, I've found.
I've seen the same behavior, even on high resolution monitors.

In response to PaulKroll's comment Conversely, nothing prevents a computer set to 16 bit color ("thousands of colors") from choosing the wrong (but close) colors for the background gif instead of the wrong colors for the background table color, so you might find it's just as big a problem for your users with or without the tiled gifs. I think maybe Kitchin is not making a point so much about "exact" colors, but matching colors. For example, if I have a logo rendered on a blue background that will be placed on the blue background of a site, I want both the site's background color and the logo's blue background color to match. By saving a gif with the logo's blue background color and setting the site's background image to this gif, I can be reasonably sure that both the logo and site background colors match. True, the browser might approximate the blue color, but at least there will be consistent approximation. This doesn't always work out so well if you simply set the background color to the same hex value as your logo's background color.

Matt

thudfactor

06-14-2002, 01:28 PM

Originally posted by agallager:
When I looked at the AAAS bar, the background is just a flat color (6666CC) not a pattern. Why not just fill the banner cell with the right color, instead of tiling background gifs (whether small or large)? Maybe I'm missing something...
:) What you're missing there is the darker blue line directly below #6666CC. I think the same thing could be done with table cells, of course, but less accurately.

kitchin

06-14-2002, 01:30 PM

Experimenting with it a bit, I found almost no advantage to using a backgound gif versus the web-safe bgcolor #6666cc. (You would think) the problems are when the display is set lower than 24-bit true color. My results (in Win98):

Display browser bgcolor=#6666cc background=6666cc.gif
24-bit IE 5 #6666cc <- same
24-bit NS 4 #6666cc #6067cf
16-bit IE 5 dither of <- same
#6060cf,
#6060c0 &
#5f5fc0
16-bit NS 4 #6060cf <- same

Even a web-safe color can change at 16 bits.

If you are trying to match the background to a foreground image, then bgcolor is fine except in Netscape 4 at 24-bit, which is not a significant share of browser platforms. I think you can tell IE whether to dither?

Note, foreground gifs rendered to the same colors as background gifs in all cases. Also, 32-bit is the same as 24-bit (triplet of colors = 3 x 8 = 24 bits).
:QTband: :QTjester: :QTpaint: :SAfrica: :elvis:

kitchin

06-14-2002, 01:40 PM

One more thought: I'm sure you've come across as many people as I have who've let their computers go down to 256 colors (=8 bits). Probably a more "significant" share than people with NS 4 at 24 bits of color! So some more experiments are in order, but not by me today.:elvis:

PaulKroll

06-14-2002, 03:57 PM

bgcolor is fine except in Netscape 4 at 24-bit
Well if that isn't the goofiest bug I've seen in a long while. What the HECK can they be doing behind the scenes to get to THAT number...?

Can't wait to put a stake in the heart of NS4.x. :)

(Did you try it with Mozilla or NS 6.2+, kitchin?)

thudfactor

06-14-2002, 04:02 PM

The "standard browser" here where I work is Netscape 4.61. ~#

PaulKroll

06-14-2002, 04:12 PM

The "standard browser" here where I work is Netscape 4.61.
Wow. Do they let you have desks and chairs? :)

sheila

06-14-2002, 04:22 PM

This is not uncommon, especially in large corporations. My husband works for a major airline manufacturing company (starts with "B"), and I'm not sure if NS 4.7 is STILL the standard browser (I suppose with the recent advances in Mozilla, it is possible that they've changed), but just four months ago, it was. (Maybe I will ask hubby tonight about that.)

--The bigger they are the slower they move.