Regarding Graphics During Heavy Free Republic Traffic

[Ichneumon]

[Folks, please do not post photos from servers that are very very very slow. Threads simply will not load if your graphic freezes on loading. When you post a grahic that doesn't work, it can practicly kill a thread.]

Ah, but apparently if the WIDTH and HEIGHT modifiers are used, the slow graphics will not cause the thread to freeze on loading.

Note, by the way, that despite the fact everyone likes to flame Microsoft's Internet Explorer, it's one of the few browsers that does *not* halt loading of a thread while it waits for images to be retrieved. It's extremely fast and efficient displaying webpages with sluggish graphics -- it displays what it can immediately (i.e., all the text), and then later reformats "on the fly" as the images finally arrive.

The most notorious browser with the annoying "I'm not going to show you anything after the graphics until I *get* the graphics" behavior is Netscape/Mozilla. That's one of the reasons I dumped Netscape long ago -- there's no excuse for that sort of poorly designed behavior.

[Ichneumon]

This is because many browsers, if these attributes are not included, will not load the rest of the thread until it can completely download the image, since the browser does not know how much space to leave for the image.

Close, but not quite. It doesn't need to "completely" download the image, it only needs to get the "header", which is in the first hundred or so bytes of the image.

The bad news is that on slow servers, you won't get *any* part of an image until after a considerable delay, so you still have to sit and wait.

The good news is that for very large or high-resolution images, you don't have to wait for *all* the image to be downloaded -- the web page can format itself after receiving just the first few percent of the image, then all you have to wait on is to see the rest of the big image.

[Ichneumon]

Not A Mod: I usually add the height size and often don't include the width size. From your post, then, am I to assume that having only ONE dimension slows the loading the same as NOT having ANY size specified in the graph template? . . .

Correct, because then the browser still has to wait to receive the original image header itself in order to calculate the "missing" dimension, and you're right back to the original problem.

Supplying only one dimension works fine if your only concern is to grow/shrink the image while maintaining the original aspect ratio, but it unfortunately doesn't help the problem of some browsers (*cough*Netscape*cough*) not wanting to display the rest of the page until it can figure out the image size(s).

[Hegewisch Dupa]

With the possible exception of Good Friday, I want fireworks for ALL holidays. Weekends too.

[Jay D. Dyson]

While it does not now, if you go back and read the original post, general_re was suggesting that the FR server COULD go out and determine the image size attributes, then automatically insert the image size attributes into the html for that user's post.

Ah. Missed that.

Sadly, such a system would make FR an easy target for a denial-of-service attack. All that would be required would be a few morons from the DU crowd to post a buttload of bogus images on servers that respond only once every sixty or ninety seconds. That would cause the server connection from FR to hang and then timeout. Meanwhile, the process table on the FR system would fill up with all these hung outbound connections to the point that it would stop answering incoming web requests. Bang. Denial-of-service.

Sorry, I can't hop on board with that plan. It's ill-conceived and fraught with potential for abuse.

-Jay

[general_re]

But it only has to grab each image headers once per image, at preview time. After that, it's hardwired into the HTML. The bandwidth overhead should be negligible

If we assume that an image on some remote server - that neither you nor I nor FR has any control over - remains static, that could work. IOW, if someone substitutes a new image in under the old file name, all bets are off. Most of the time that's probably a safe assumption, but not always, I think...

[Mark Hamilton]

Thanks I'll try again

[MeekOneGOP]

Okay. Thanks. I save a lot of my repeat graph posts in Word for an easy cut 'n paste method. I'll be updating them as I go along then.

Thanks for the help and information . . .

[Mark Hamilton]

I'll try again www.bccls.org/images/ 0060393408.jpg

[justshe]

Perhaps they simply did not understand the actual logistics and are NOT ......as you so eloquently put it......."graphic turds".

Goodness!

[Physicist]

True, but that caveat also applies to a poster coding it by hand.

[SamAdams76]

Just testing this theory out...height=338, width=450

[SamAdams76]

Now this is with the height and width reversed...

[Fixit]

You used the tags correctly, but you did not create a version of the image at the size to be displayed.

Your original image at http://www.bccls.org/images/0060393408.jpg has a native resolution of 312 x 475, as displayed here.

Not only does the graphic look blocky due to the poor job that most browser's do resizing images, but you took over 35K to do what could have easily been accomplished in under 12K.

<---- This is under 12K and displayed at its native 200x305 resolution

This is over 35K and displayed at a
slightly squished 200x300 resolution ---->

The image on the right looks (artificially) a bit sharper, but only becuase of the way the browser truncates pixels to shrink the image. This is especially noticable around Hillary's evil eyes.

Compare also the quality of the text in each. The smaller image, to my eyes, looks smoother and more correct.

[Brad’s Gramma]

Now I'm confused Ping.

[Musket]

Thanks. I did not know that some browsers choke if the width and height aren't included.

[supercat]

Such a system would (marginally) add some bandwidth to the FR server at the time of posting, but it could serve to increase everyone elses enjoyability by easing all future downloads.

How about having FR give some javascript to the poster's browser if any image sizes are not included, and have that javascript figure out and tell FR the proper sizes?

[supercat]

If we assume that an image on some remote server - that neither you nor I nor FR has any control over - remains static, that could work. IOW, if someone substitutes a new image in under the old file name, all bets are off. Most of the time that's probably a safe assumption, but not always, I think...

On the other hand, if the server is one which feeds "remote linking not permitted" pictures when shown in an FR post, having the FR server attempt to get image dimensions and include them would reveal the problem. Otherwise, someone who first views a picture in an "approved" manner and then links to it will see his own post correctly while others will see a "forbidden" banner.

[drq]

As easy as making Jello.

[Mark Hamilton]

I'm a little confused. At first you said that the original image had a resolution of 312x475, then below that you displayed the "native" image as 200x305, which is the native image???

I gather that one should display the images in there original resolution (found under properties?).