Text and Image Crawler v1.5 Speed difference in different browsers

[philrutter]

1) Script Title: Text and Image Crawler v1.5

2) Script URL (on DD): http://www.dynamicdrive.com/dynamici...wler/index.htm

3) Describe problem: Not a big issue, but I have a working Crawler, that appears to run fine in Chrome, MS IE, Opera, but moves very slowly in Firefox. Page in question is https://www.bksts.com/secure/about.asp. Just wondering if this is typical - I couldn't find any other threads or comments on the subject.

Also, just for information, I discovered that if a JPG image that has been generated in CMYK colour space is used with this script, then although it will render correctly in most browsers, it will not do so in MS IE - relatively simple to fix, but it took some time to trace.

[djr33]

Also, just for information, I discovered that if a JPG image that has been generated in CMYK colour space is used with this script, then although it will render correctly in most browsers, it will not do so in MS IE - relatively simple to fix, but it took some time to trace.

Which image is this? (Can you link to it, or is it already in your demo?)
I'd be surprised if that's specifically due to this script. Have you tried it in other contexts (eg, just an <img> tag)?

[jscheuer1]

I detect no difference in speed between Opera 12.02 and Firefox 16.0.1, both under Win 7. Both appear to be at a good rate. Perhaps your Fox is outdated, and/or your computer's resources are or at the time were low - Firefox does require more memory and CPU ticks than just about any other browser, even for the simplest scripts, and this is a fairly simple script. The fact that you have another similar script on the same page is another contributing cause. Even when Firefox is taxing a computer, it can often still manage one such feature on a given page. But if there are two, it becomes harder for it to do so without slowing one or both of them down and/or making one or both of them choppy/jumpy. It also gets harder for the Fox if there are multiple tabs open and other animations are running in those, and/or any other browsers are open with or without running animations in them.

But with enough memory and CPU time, Firefox is generally fine with these things.

When I test things in the Fox, if there are problems of that nature, I always shut down as many other things as possible to see if it's a resource thing or just Firefox.

When I tested your page, I just happened to have very little (relatively speaking) else open. That could account for why it looks good to me in Firefox.

OH, and about the image you were talking about. Yes that's a limitation of IE, not the script. I'm not 100% sure but I believe IE 9 now supports those CMYK images though.

Later . . . Oh, and I see there's an animated GIF image on the page as well. These also tax Firefox. But, as I say, it's all working fine in the Fox here.

[philrutter]

Thanks for the responses. The CMYK problem might be something to do with the way the files are being extracted from a database - the original CMYK versions appear to read OK in MS IE 8, but I can't easily simulate how they are being extracted to the Crawler script. Anyway, that problem is easily fixed - I'll only work with RGB files!
Regarding speed, I am running XP Pro, on a 10 year old PC, so maybe I'm expecting too much. Firefox is certainly taking up to 92% of CPU resource, so maybe the idea of running 3 instances of the Crawler on a single page with up to 100 graphics per Crawler may be running the risk of a major conflagration - that'll give me a good excuse for getting a new PC!
Many thanks for the help

[jscheuer1]

On the image, you're right. What you're saying has jogged my memory of when this happened before. The image in question at that time could be re-saved in The Gimp (a free advanced image editing program like PhotoShop), as a CMYK image using The Gimp's defaults for CMYK images and it would show up in IE. However it was much larger byte wise than an identical looking version saved using RGB. So at that time I recommended using RGB only. But it points up that there likely are different kinds of CMYK images, some IE can read, others it can't.

So I think I know what happened. In extracting from the database the image was either recreated from itself with itself as data for (I'm guessing PHP-GD or ImageMagick, etc.) creating it, or created from stored data read and saved into the database earlier from the image itself. What I'm thinking is, even though the data was obtained from a readable by IE CMYK version of the image, the algorithm used by PHP or whatever server side language you're using to create/re-create the image, makes a certain type of CMYK image that IE cannot read.