 |
Author |
Topic: Different loading times with different JVMs (Read 2596 times) |
|
marcello
 
|
Different loading times with different JVMs
« on: Apr 9th, 2005, 7:46pm » |
|
Hi all,
I noticed a strange behavior of my computer when applets are loading according to whether I use the Microsoft JVM or Sun Java 1.4.2_08. The main difference is the loading time.
I've done an experiment that gave very strange results that I'm not able to understand. Here is what I've done.
Before all I deleted all the temporary internet files to be sure that the loading time of the applet were not affect to previous data resident in my computer. After I set my browser (IE 5.5) to use the Microsoft JVM, and then I restarted the system. After I got the connection I clicked the link to the applet D5LV by Frederik Vanhoute in Exhibition (a small and tidy applet) looking at the number of bytes downloaded on my computer. The number of bytes that have been downloaded on my computer to run the applet were about 153000.
After I deleted again all the temporary internet files, I set the browser with the Sun Java 1.4.2_08, and I restarted the system. I got once again the connection and I clicked the same identical link to the previous applet. This time the number of bytes downloaded on my computer were about 473000.
My system is: Windows Me, IE 5.5, firewall: zone alarm, a simple and free antivirus: avast.
To start the same applet:
Microsoft JVM =>153000 byte downloaded
Sun Java 1.4.2_02 => 473000 byte downloaded
I really don't know the reason of all this difference. I would be grateful if someone could explain me why the Sun Java needs to download a greater number of data compared with the Microsoft JVM.
Thank in advance,
Marcello
|
|
|
|
|
fry
|
Re: Different loading times with different JVMs
« Reply #1 on: Apr 9th, 2005, 11:35pm » |
|
it seems that at some point, the sun jvm started re-downloading the .jar file for each image individually. so i'm guessing you have 4-5 images in your project, causing your applet to be re-downloaded 5x. it's pretty annoying and we're looking into why it started happening, and how to fix it.
i think there's a thread with a post from toxi elsewhere on the board that has a temporary fix.
|
|
|
|
|
marcello
|
Re: Different loading times with different JVMs
« Reply #2 on: Apr 10th, 2005, 10:31am » |
|
Quote:| it seems that at some point, the sun jvm started re-downloading the .jar file for each image individually. so i'm guessing you have 4-5 images in your project, causing your applet to be re-downloaded 5x. it's pretty annoying and we're looking into why it started happening, and how to fix it. |
|
Oh! Now i understand. Anyway I did the experiment on an exhibition's applet (not mine) so that anyone would have been able to repeat it again. But actually I found out this strange behavior on an other applet of mine. There i used the Glen Murphy's Fast Text where i added a number of other fonts. Now it is all clear. Thank you very much.
Quote:| i think there's a thread with a post from toxi elsewhere on the board that has a temporary fix. |
|
Now i'll look for that thread. When i'll find it, i'll insert here the link. Thank you again.
Marcello
|
|
|
|
|
marcello
|
Re: Different loading times with different JVMs
« Reply #4 on: Apr 15th, 2005, 3:16pm » |
|
Hi,
i'm sorry to disturb you all again but now i've a problem with the toxi's code i found in this old thread:
http://processing.org/discourse/yabb/board_Programs_action_disp_lay_num_1078795681.html
The code that i'm talking about is:
Code:public BImage loadImage(String file) {
try {
byte[] imgarray=loadBytes(file);
java.awt.Image awtimage=Toolkit.getDefaultToolkit().createImage(imgarray);
MediaTracker tracker = new MediaTracker(this);
tracker.addImage(awtimage, 0);
try {
tracker.waitForAll();
} catch (InterruptedException e) {
e.printStackTrace();
}
int w = awtimage.getWidth(null);
int h = awtimage.getHeight(null);
int[] pix = new int[w*h];
PixelGrabber pg = new PixelGrabber(awtimage, 0, 0, w, h, pix, 0, w);
try {
pg.grabPixels();
} catch (InterruptedException e) {
e.printStackTrace();
}
BImage img=new BImage(pix,w,h,RGB);
if (file.toLowerCase().endsWith(".gif")) {
for (int i = 0; i < pix.length; i++) {
if ((pix[i] & 0xff000000) != 0xff000000) {
img.format=RGBA;
break;
}
}
}
return img;
}
catch(Exception e) {
return null;
}
} |
|
This code should avoid the reloading of the entire .jar file each time the command loadStrings() is called.
I Followed toxi's instructions:
Quote:| okay, for the interim period, here's a fix for loadImage() which doesn't cause the JAR to reload... just include it in your sketch and it'll overwrite the existing version. |
|
but i did something of wrong since when i run the sketch appear the two errors:
Quote:| Semantic Error: Type java.awt.BImage was not found. |
|
and:
Quote:| Semantic Error: Ambiguous invocation of constructor "PixelGrabber". At least two constructors are accessible from here: "PixelGrabber(java.awt.Image $1, int $2, int $3, int $4, int $5, int[] $6, int $7, int $8 );" and "PixelGrabber(java.awt.image.ImageProducer $1, int $2, int $3, int $4, int $5, int[] $6, int $7, int $8 );". |
|
Probably it is a silly thing but i'm not able to solve the problem by my own.
I'm using processing 68. Could be also important to say that when the errors are displayed, the following row of the above code is highlighted:
Code:| java.awt.Image awtimage=Toolkit.getDefaultToolkit().createImage(imgarray); |
|
Thanks in advance for your help.
Marcello
|
|
|
|
|
marcello
|
Re: Different loading times with different JVMs
« Reply #5 on: Apr 16th, 2005, 3:32pm » |
|
...anyway it is not a so important thing since it is clear that to avoid that problem it is enough to place the images directly in the web space and call them using loadImage() on an absolute URL. 
Best Regards,
Marcello
|
|
|
|
|
fry
|
Re: Different loading times with different JVMs
« Reply #6 on: Apr 16th, 2005, 6:29pm » |
|
on Apr 16th, 2005, 3:32pm, marcello wrote:| ...anyway it is not a so important thing since it is clear that to avoid that problem it is enough to place the images directly in the web space and call them using loadImage() on an absolute URL. |
|
yeah, tho if that's all we can do from now on, we should stop packaging the images into the .jar file so that people don't have to do that sort of silliness themselves.
|
|
|
|
|
|
