 |
Author |
Topic: Jar files and network weirdness (Read 2425 times) |
|
stungeye
|
Jar files and network weirdness
« on: Mar 9th, 2004, 2:28am » |
|
The following post deals with his applet:
http://www.stungeye.com/processing/0304/index.html
The applet in question loads 127 jpgs (from an MRI scan) and animates them sequentially.
I exported the jar and index.html file with the publish option.
From my local PC, I can load the index.html in a web-browser and the applets functions normally.
However, once I've uploaded the published applet to my webserver it no longer functions.
The jar file will begin to download and the downloading will never end! I've monitored my network traffic to confirm this; once the applet begins to download it never stops. (The jar file is under 2MB but the web-browser will continue to load data once 2MB has been downloaded.)
Has anyone else experienced this kind of never-ending .jar file?
Thanks,
WG
P.S. The webserver in question loads other processing applets without any problems.
|
| « Last Edit: Mar 9th, 2004, 2:41am by stungeye » |
|
|
|
|
arielm
|
Re: Jar files and network weirdness
« Reply #1 on: Mar 9th, 2004, 10:19am » |
|
something that worked for sure with older versions of processing (not sure it still does today):
to store the images outside of the .jar file (to remove stuff from a .jar: it's simple as temporarely rename it to .zip and edit it...)
+ it won't affect the overall download time, since jpegs are uncompressible anyway
hth...
|
Ariel Malka | www.chronotext.org
|
|
|
toxi_
Guest
|
Re: Jar files and network weirdness
« Reply #2 on: Mar 9th, 2004, 12:58pm » |
|
i experienced the same thing recently and am not yet sure what's causing it and need to do more tests. but it might have something to do with the java plugin cache settings. it seems like for every loadImage(), loadStrings() etc. the entire .jar is reloaded. is that possible?
|
|
|
|
|
stungeye
|
Re: Jar files and network weirdness
« Reply #3 on: Mar 9th, 2004, 5:21pm » |
|
Removing the images from the jar file helped:
http://www.the-space-lab.com/kyle/index2.html
(I also switched to a faster server for testing purposes.)
***
Because the images still load slowly, I wanted to add a download progress bar.
Is there anyway to force processing to draw lines while inside the setup() block? I had to kludge the progress bar into the loop() block.
Because of this, once all the images load (and the core of the loop() block begins), the framerate is all out of wack. (i.e. It is trying to catch up for the time lost during the kuldged progress bar.)
I've tried scaling the framerate during the progress bar and then ramping it afterwards. This only somewhat improves the kludge.
Is it possible to 'flush' the timeframe counter?
Thanks,
WG
Note, brain images were found here:
http://mind-brain.com/my_atlas.html
|
|
|
|
|
fry
|
Re: Jar files and network weirdness
« Reply #4 on: Mar 10th, 2004, 2:32pm » |
|
with the timages loading slowly, rather than monkeying with setup/loop, i'd recommend that you add a thread to load the images (i've done this in this project: http://acg.media.mit.edu/people/fry/zipdecode/ to load the cities over a slow connection).
the thread looks something like this:
Code: class Slurper implements Runnable {
int IMAGE_COUNT = 100;
int imageCount;
public Slurper() {
Thread thread = new Thread(this);
thread.start();
}
public void run() {
// loop through and load the images here
for (int i = 0; i < IMAGE_COUNT; i++) {
image[i] = loadImage("image" + i + ".jpg");
imageCount++;
}
}
public float howfar() {
return (float(imageCount) / float(IMAGE_COUNT));
} |
|
then you add the following to your main class:
Code:Slurper slurp;
void setup() {
// add this to the end
slurp = new Slurper();
}
void loop() {
if (slurp != null) {
background(slurp.howfar() * 255); // uh, progress "bar"
if (slurp.imageCount == slurp.IMAGE_COUNT) slurp = null; // done
} else {
// all images loaded, draw as necessary
}
} |
|
something like that, at any rate (i'm kinda writing off the top of my head, so i mighta missed something..)
i'd be curious to know what's up with the jar issue if you find anything... that could be a huge issue, meaning that we should start moving all the data files outside the jar (ugh).
|
|
|
|
|
TomC
|
Re: Jar files and network weirdness
« Reply #5 on: Mar 10th, 2004, 3:43pm » |
|
I've done somthing similar with Threads for preparing a big data set. Unfortunately, if you run it inside processing, hitting "stop" or closing the window doesn't stop the thread.
e.g. Try running this, stopping it, and starting another one. Notice the mess it makes in the console.
Code:
int progress;
void setup() {
new Thread(new Runnable() {
public void run() {
for (int i = 0; i < 1000; i++) {
progress = i;
println(i);
try {
Thread.sleep(100);
} catch (InterruptedException e) {}
}
}
}).start();
}
void loop() {
background(progress%255);
}
|
|
Any idea on solutions for this?
Thinking outloud... I looked into overriding the stop method for the applet and sending a message to stop the Thread, but Thread.stop() is deprecated, and just setting the Thread to null doesn't do it - what about putting a public flag inside the Runnable implementation, setting this to false on stop, and checking it inside run()?
Update: answering my own question. This works.
Code:
int progress;
class MyRunner implements Runnable {
boolean finish = false;
public void run() {
for (int i = 0; i < 1000 && !finish; i++) {
progress = i;
println(i);
try {
Thread.sleep(100);
} catch (InterruptedException e) {}
}
}
}
MyRunner myRunner;
void setup() {
myRunner = new MyRunner();
new Thread(myRunner).start();
}
void loop() {
background(progress%255);
}
public void stop() {
myRunner.finish = true;
}
|
|
|
| « Last Edit: Mar 10th, 2004, 3:47pm by TomC » |
|
|
|
|
stungeye
|
Re: Jar files and network weirdness
« Reply #6 on: Mar 10th, 2004, 3:45pm » |
|
I just checked my server logs and they confirm the "never -ending jar" theory.
300MBs of data uploaded during the testing of this applet. That's a lot of traffic for an applet with a <2MB jar file.
Is Toxi's theory possible? Is the entire jar file being re-cached on each call of loadImage()?
WG
Update:
Added the threaded loading. Works great.
One small issue: The thread couldn't loadImage() remote files. (i.e. images stored on another webserver.) Works fine, however, for images stored on the applet's webserver.
Here's the final sketch:
http://www.the-space-lab.com/kyle/processing/0304/index.html
Thanks for the help y'all!
|
| « Last Edit: Mar 10th, 2004, 5:18pm by stungeye » |
|
|
|
|
toxi_
Guest
|
Re: Jar files and network weirdness
« Reply #7 on: Mar 10th, 2004, 6:11pm » |
|
for security reasons, a java applet can only load data from its own domain. loadImage() is no exception 
re:jar file issue - the culprit is found, though you'll have to wait for the fix until the next revision as it's part of loadImage()...
|
|
|
|
|
toxi_
Guest
|
Re: Jar files and network weirdness
« Reply #8 on: Mar 10th, 2004, 8:15pm » |
|
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.
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;
}
}
|
|
|
|
|
|
|
fry
|
Re: Jar files and network weirdness
« Reply #9 on: Mar 10th, 2004, 8:30pm » |
|
i can't believe that javasoft were such goobers that they thought it'd be a good idea to reload the jar when downloading each file from within it. i hope it's just because we're doing something wrong, rather than them just being completely (use your own adjective).
will use a variation of toxi's code for 69. thanks for tracking down and providing a fix for this guys. much 'preciated.
update:
seems that it's partially p5's fault because image caching is turned off by default--because of other folks having trouble getting the 'new' version of images they've changed or are being loaded from a webcam.
fix:
use loadImage(filename, false);
the 'false' means 'don't force images to reload', meaning that it'll turn java's image cache back on.
though javasoft are still a bunch of goobers for not being able to tell that the file is from a static jar. oh well. i feel better that it's not something quite so silly.
guess we'll have to document this better (at all  ) in the reference.
|
| « Last Edit: Mar 10th, 2004, 8:35pm by fry » |
|
|
|
|
|
