Problem with MediaTracker

[Giox]

Good morning,
I have a problem with an applet using AWT MediaTracker class, and I
would like to know if someone else faced and solved this issue.
The code that I propose at the end of the post should read an image
and display it in an applet, refreshing it each time it is loaded.
This applet works fine with typical browser (IE and Firefox) and Java
1.5.XXXX, but doesn't work with the same browsers and Java 1.6.XXXX.
With this java version however everything works fine if I watch at the
applet in the appletviewer debugging it in Netbeans. Nothing happens
however if I watch at the applet in the web browser.
In fact it seems that the applet reads the image only the first time
it is loaded, but then changing the image on the hard disk doesn't
generate an update of the displayed image.
I set up a policy file where the applet is compiled using
grant {
permission java.security.AllPermission;
};

Please note that the applet doesn't crash since the
showStatus("Image Number: "+indexDisplayed);
doesn't stop updating.
I think that the code lines

tracker.removeImage(myImage);
myImage.flush();

should work correctly but it seems that Java 1.6 changed the meaning
of these instructions, when executed in a web browser.
In the next rows I propose a section of the applet.
Thanks a lot for your help.
Giovanni.

********************************
import java.awt.*;
import java.applet.*;
import java.net.*;

public class easyCamGio extends Applet {
private Image myImage = null;
private int indexDisplayed=0;

private String fileBase;
private String fileExtension;

private Thread timerThread;
private volatile boolean noStopRequested;
private MediaTracker tracker;

private void startThread() {
noStopRequested = true;

Runnable r = new Runnable() {
public void run() {
runWork();
}
};

timerThread = new Thread(r, "Timer");
timerThread.start();
}

private void runWork() {
boolean imageload = false;

try {
while ( noStopRequested ) {

// Get the image saved on the Hard Disk
myImage = getImage(getDocumentBase(), fileBase + "1" +
fileExtension);
// Add the image to MediaTracker
tracker.addImage(myImage, 0);
// Wait for the image
tracker.waitForAll();
imageload = true;

showStatus("Image Number: "+indexDisplayed);
indexDisplayed = indexDisplayed+1;

repaint();

// Remove the previously loaded image from the tracker and set it
to null
if( imageload == true ) {

tracker.removeImage(myImage);
myImage.flush();
myImage = null;
}

}
} catch ( InterruptedException x ) {
showStatus("runWork() Exception");
Thread.currentThread().interrupt();
}
}
}

********************************

 

[Andrew Thompson]

Giox wrote:
...

The code that I propose at the end of the post should read an image
and display it in an applet, refreshing it each time it is loaded.

No. That code was a waste of bandwidth.

After fixing the wrapped line and changing the hard coded
image name (had you ever heard of the applet param element?),
I realised that it was missing an init() or a paint(), and called
none of the methods of interest.

After overriding paint to draw the image, and adding an init() to
create the MediaTracker, and kick off that horrendous loop..
I forgot what the question was.

Oh yeah - 'image caching'. Yeah (shrugs) The Java Plug-In
is terribly 'cachey' of images. I am more surprised that your
code worked in earlier (or any, for that matter) VMs, than
that it breaks now.

There are a number of ways to get around the image caching,
the most reliable way is to load the image as bytes, then use
the Toolikt.createImage(byte[]) method to stamp it out to a
usable graphic.

A few other comments.

I set up a policy file where the applet is compiled using
grant {
permission java.security.AllPermission;
};

What on earth possessed you to do that? This
applet requires no extended permissions.

...

I think that the code lines

tracker.removeImage(myImage);
myImage.flush();

should work correctly but it seems that Java 1.6 changed the meaning
of these instructions, when executed in a web browser.

If you can get the behaviour you want in the AppletViewer,
you can get the same effect by launching the applet
using Java web start. JWS uses the applet viewer.

In the next rows I propose a section of the applet.

'sections' of applets are usually no good. Please consider
posting SSCCE code that others can work with, without
having to try and 'guess' what was in the other 'missing' parts
of the code.
<http://www.physci.org/codes/sscce.html>

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[Giox]

Giox wrote:

..


No. That code was a waste of bandwidth.

Sigh this code has been set up by the software programmer that
provided me this applet, as you unserstood I'm not at all a Java
programmer. This applet is used in an embedded platform that should
provide the image.

After fixing the wrapped line and changing the hard coded
image name (had you ever heard of the applet param element?),
I realised that it was missing an init() or a paint(), and called
none of the methods of interest.

After overriding paint to draw the image, and adding an init() to
create the MediaTracker, and kick off that horrendous loop..
I forgot what the question was.

Oh yeah - 'image caching'. Yeah (shrugs) The Java Plug-In
is terribly 'cachey' of images. I am more surprised that your
code worked in earlier (or any, for that matter) VMs, than
that it breaks now.

There are a number of ways to get around the image caching,
the most reliable way is to load the image as bytes, then use
the Toolikt.createImage(byte[]) method to stamp it out to a
usable graphic.

A few other comments.

I set up a policy file where the applet is compiled using
grant {
permission java.security.AllPermission;
};

What on earth possessed you to do that? This
applet requires no extended permissions.

I set up this policy while trying to load and use the applet from
appletviewer on my PC (it returned an error)

..


If you can get the behaviour you want in the AppletViewer,
you can get the same effect by launching the applet
using Java web start. JWS uses the applet viewer.


'sections' of applets are usually no good. Please consider
posting SSCCE code that others can work with, without
having to try and 'guess' what was in the other 'missing' parts
of the code.
<http://www.physci.org/codes/sscce.html>

You are right but I thought it was not too kind to send the whole
code, I was hoping the problem could be found in the runWork method

 

[Andrew Thompson]

Sigh this code has been set up by the software programmer that
provided me this applet, ..

Any Java programmer worth paying, would not have produced
such rubbish. Truly, there were many aspects in the code
that made me think you were a keen learner who had gotten
out of their depth. A 'keen learner' can make such (and so
many) mistakes without too many repercussions, but
somebody who is supplying code for others, should
know better.

...as you unserstood I'm not at all a Java programmer.

I do now - I didn't then. We get many learners here, few
of them would have been able to state the problem as
clearly as you did.
...

I set up this policy while trying to load and use the applet from
appletviewer on my PC (it returned an error)

My (altered) version loaded the image successfully, from
a path relative to the codebase - no 'extended permissions'
required.

...

You are right but I thought it was not too kind to send the whole
code, I was hoping the problem could be found in the runWork method

..dump that code. Honestly, it is rubbish. It would be
quicker to write* again from scratch, than fix the many
problems with it.

* And if that means hiring a new programmer - so be it.
Whoever gave you that code does not deserve feeding,
let alone paying.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[Giox]

Any Java programmer worth paying, would not have produced
such rubbish. Truly, there were many aspects in the code
that made me think you were a keen learner who had gotten
out of their depth. A 'keen learner' can make such (and so
many) mistakes without too many repercussions, but
somebody who is supplying code for others, should
know better.

To be honest, this code sample has been provided in a example by Texas
Instruments, I hoped that it was ok, but now I think they used a "low"
cost programmer

I do now - I didn't then. We get many learners here, few
of them would have been able to state the problem as
clearly as you did.
..

Thanks , I devoted last weekend to read some old University
book

My (altered) version loaded the image successfully, from
a path relative to the codebase - no 'extended permissions'
required.

I will try to code a new applet following the ideas that you provided
me

..



.dump that code. Honestly, it is rubbish. It would be
quicker to write* again from scratch, than fix the many
problems with it.

* And if that means hiring a new programmer - so be it.
Whoever gave you that code does not deserve feeding,
let alone paying.

Sigh I will try to contact TI.
Or better I will try to code it by my self
Thanks again for your help