Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Re^2: Manipulating Images (height and width)

by sauoq (Abbot)
on Sep 09, 2002 at 18:49 UTC ( [id://196392]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Manipulating Images (height and width)
in thread Manipulating Images (height and width)

Why send an 80kb 400x400 image scaled to 40x40 with IMG attributes when a real 40x40 one would be 4kb?

One possible reason is if the 400x400 image is expected to be viewed later. Why send 4kb 100 times and then 80kb 95 times when sending 80kb 100 times will do? In your example, this justification would only work if the larger image were requested about 95% of the time (though that would still win with protocol overhead) but, with different images, that ratio could be a lot lower. There is no substitute for traffic analysis.

Another reason might be because generating thumbnails on the fly is expensive in terms of both CPU and time. You might argue that one should then generate the smaller images ahead of time but that approach could be costly in terms of disk and, perhaps more importantly, maintenance issues. These problems could be compounded by the need for multiple thumbs of different sizes.

Having many ways to do things is so desirable because which of those ways is best usually depends on the problem at hand.

-sauoq
"My two cents aren't worth a dime.";
  • Comment on Re: Re^2: Manipulating Images (height and width)

Replies are listed 'Best First'.
Re^4: Manipulating Images (height and width)
by Aristotle (Chancellor) on Sep 09, 2002 at 19:31 UTC

    You do have a point. In theory. I haven't run across a case in practice yet where you could expect both the scaled down and original size image to be viewed with that kind of certainty.

    As for thumbnails, I am on a slowish connection and I consider it rude if someone is too lazy to put up scaled down thumbs to serve; more than likely I'm not going to bother waiting for the gallery to load.

    The only case where it is realistically sensible to use IMG attributes is when the same image is used in various scaling factors on the same page - which is usually the scaled transparent pixel scaler..

    Makeshifts last the longest.

      You do have a point. In theory. I haven't run across a case in practice yet where . . .

      Ah. Well, I actually have. Among other things, the company I work for provides web access to a service which we customize for our clients. Our clients are themselves large companies. Part of the customization includes branding the site with their logos. We request that they provide us with a single logo image of a particular size and a transparent background. We use the single image in various places in, I think, three different sizes. The primary reason we choose to use one image rather than three is to avoid maintenance issues.

      As Steven Wright has said, "It's a small world, but I wouldn't want to have to paint it."

      -sauoq
      "My two cents aren't worth a dime.";
      
        That is a special case of the "used in various sizes on the same page" rule, I'd say.. :-)

        Makeshifts last the longest.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://196392]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others admiring the Monastery: (2)
As of 2024-04-26 01:17 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found