PDA

View Full Version : Standard or Progressive jpegs for FadeSlideShow?



ccesca
02-22-2012, 03:24 PM
1) Script Title: FadeSlideshow

2) Script URL (on DD): http://www.dynamicdrive.com/dynamicindex14/fadeinslideshow.htm

3) Describe problem:

I have problem where if I am looking at one page, where i have a slideshow, it fades in nicely from the first image. But if i leave that page, when i come back to the original page, the image doesn't fade in nicely again, instead, it looks like it loads downwards.

I have payed around with making my images standard, or progressive... but i can't seem to notice a difference.

What do you recommend using of the two image jpeg types?

is there another reason why it might be doing this? It's unfortunate because it looks clunky instead of smooth, if you ever re-visit a page you've already looked at once.

Thanks in advance of any help or advice...

ccesca

jscheuer1
02-22-2012, 03:43 PM
In this situation the only reason to choose between standard and progressive for jpeg is the byte size of the image. You want the smaller byte size. And should go beyond that - optimizing the images for the smallest possible byte size that maintains acceptable resolution.

It's not been my experience that revisiting a page with this slideshow causes the problem you're reporting. I suppose that if you left the page before all of the images were cached, that might cause it. But it might not. That's another reason to go for the smallest possible byte size on the images. If you have a really small cache size set for the browser that might be it.

So it might be browser specific.

What browser (version and OS) are you using?
Does this happen if you visit the demo page for this script here on Dynamic Drive?

If you want more help, please include a link to the page on your site that contains the problematic code so we can check it out.

ccesca
02-22-2012, 03:48 PM
Hi John,

Thanks so much for responding.

No, it does not happen when i look at your examples on this site...

I am using Firefox 10.0.2 on a Mac. It's ben happening (on the site I'm mentioning) on the past few versions of FF also...

Here is a link which may illustrate the issue for you:

http://tinyurl.com/fadeclunky

(or not??)

Any ideas?

ccesca

ccesca
02-22-2012, 03:51 PM
Hmmm.. it's only happening in Firefox :mad:

It seems find in Chrome, Safari and Opera.... on the mac

:(

Though it's weird that it doesn't happen to your small demo versions when i view them in Firefox... do you think the size is that much different?

jscheuer1
02-22-2012, 04:37 PM
Not happening here in Firefox 10.0.2 under Win 7. Unless I missed something. I viewed the page, it was fine as you say. I went to another page and then used the back button - still fine. Even if I disable the cache it's still fine. It appears there's a temporary cache on disk or in memory even if there's no permanent on disk cache. But that's under Win 7, on a Mac it could be different.

And yes, the byte size of the images could play a role. As could, if that's the case, the connection speed. Other than byte size of the images, I see no material difference between your slideshow and the DD demo version. That doesn't mean that there is none. Even if it is that, as you have seen it's also browser specific.

Out of curiosity, check your Firefox under:

Tools > Options > Advanced > Network

and see what the cache settings are.

But that might not have anything to do with it. Firefox has been scrambling of late to keep pace with innovations both Chrome and IE have been making that are impacting its market share on the PC. Mac users might suffer slightly in the meantime as Firefox concentrates on that issue.

Or it might be a third party toolbar or other add on of your Firefox, several of these have been known to cause the otherwise hard to diagnose problem with some javascript features.

ccesca
02-22-2012, 04:46 PM
Hi again,

Attached is an image of my Firefox settings.

It's odd.. I am ultimately trouble-shooting the fact that my client complains that the images take forever to load at all - but that might be because there are other javascripts on the other pages, which might be causing it all to delay loading...

But before i attempted to trouble-shoot that, there was this issue to deal with.

Since the page i send you to hasn't anything else on it to clog it up, i'm suspecting it may be what you said... a FF issue on the macs... boo hoo..

ccesca

jscheuer1
02-22-2012, 05:06 PM
Well that's the standard setting and shouldn't be impacting this. Unless it's a third party add on that's to blame, it's probably Firefox Mac.

While you were responding, I added that (toolbars and other add ons) to my list in my previous message as possible causes. You can try disabling those one at a time to see if that helps.

For your client, that's mostly their connection speed and the byte size of the images. The slideshow itself doesn't generally wait around for other scripts to load. But there could be situations where that might happen.

However, working from an empty cache I see no material difference in load time between the real home page on the site and the stripped down demo page you made.

This script is supposed to have a loading image display while the slide images load. But the script wasn't written correctly in that regard. Having the loading image there might assuage your client though. As long as you downloaded it from the demo page and it's in the same folder as the page, you can add to your css stylesheet for the page:


#fadeshow1, #fadeshow1 .gallerylayer {
background: white url(loading.gif) center no-repeat !important;
}

And add the highlighted before the on page slideshow script call:


<script type="text/javascript">
var loadingimage = new Image();
loadingimage.src = 'loading.gif';

var mygallery=new fadeSlideShow({
wrapperid: "fadeshow1", //ID of blank DIV on page to house Slideshow
dimensions: [970, 425], //width/height of gallery in pixels. Should reflect dimensions of largest image
imagearray: [
["nyc/images/new/intro.tomatoes.jpg"],
["nyc/images/new/intro.melons.jpg"],
["nyc/images/new/intro.artichokes.jpg"],
["nyc/images/new/intro.beets.jpg"]//<--no trailing comma after very last image element!
],
displaymode: {type:'auto', pause:4000, cycles:0, wraparound:false},
persist: false, //remember last viewed slide and recall within same session?
fadeduration: 800, //transition duration (milliseconds)
descreveal: "ondemand",
togglerid: ""
})
</script>

ccesca
02-22-2012, 05:09 PM
I have to run out now and won't have time to check this till tomorrow. But I absolutely will (all your suggestions) and I'll let you know the outcome!
Thank You!!

jscheuer1
02-22-2012, 05:19 PM
Don't forget about the byte size of the images in the show - optimize them for smaller byte size if possible.

ccesca
02-22-2012, 09:20 PM
The only way I know to do that is to compare what 72dpi looks like in various export formats... (comparing the byte size)

Unless you suggest/recommend trying less than 72dpi.. is that considered acceptable?

jscheuer1
02-22-2012, 09:56 PM
With jpeg you have a choice of 1% to 99& image quality.

Fist make a backup copy of the image. Next put it in your image editor and choose export as jpg. You should have a choice there or in a dialog accessible from there that gives you the option of at least quality, perhaps some other things. Also, before you export, you can sharpen it a little or a lot to make up for some of the loss of quality that you set at export. You can also add or remove progressive before or during export (depends upon your editor). There are probably other options before export if you know where to look for them in your editor.

If your editor doesn't have anything like that, what editor are you using?

Alternatively you can use an online image optimizer or get some image optimizer software.

I use Optimizer Pro from XAT. In it I took intro.tomatoes.jpg at 370 KB (378,055 bytes) down to:

http://home.comcast.net/~jscheuer1/side/intro.tomatoes.jpg

at 36.34 KB (37,211 bytes) -less than 10% of the original byte size. I did that by adding a fair amount of sharpening while reducing its quality from 98% to 68%. I also removed 'extra color' and made it standard as opposed to progressive as that saved some bytes. I also applied 50% 'magic compression' (a feature of XAT's program) to it. That only saved about 13,000 bytes, so most of the savings came from the quality reduction. And I think it's very hard to tell the difference. It will load about ten times faster than the original.

ccesca
02-23-2012, 05:46 PM
Thank you John. I'm going to try your suggestion. I've always been reluctant to do anything less than 100% image quality... but perhaps i can shave a little and it will solve my issue. I'll give you an update when I've tested it :o)

PS) I'm using Photoshop CS4