Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / December 2007

Tip: Looking for answers? Try searching our database.

Problem with MediaTracker

Thread view: 
Giox - 03 Dec 2007 09:09 GMT
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 - 03 Dec 2007 09:45 GMT
...
>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
>
[quoted text clipped - 3 lines]
>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>

Signature

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

Giox - 03 Dec 2007 13:46 GMT
> ..
>
> >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.

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?),
[quoted text clipped - 24 lines]
> 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)

> ..
>
[quoted text clipped - 17 lines]
> 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 Thompsonhttp://www.physci.org/
>
> Message posted via JavaKB.comhttp://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1
Andrew Thompson - 03 Dec 2007 14:05 GMT
>> ..
>>
[quoted text clipped - 5 lines]
>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.
...
>> ...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)

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

...
>> <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

..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.

Signature

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

Giox - 03 Dec 2007 16:49 GMT
> >> ..
>
[quoted text clipped - 13 lines]
> 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

> >...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.
> ..

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

> >> ...This applet requires no extended permissions.
>
[quoted text clipped - 4 lines]
> 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

> ..
>
[quoted text clipped - 10 lines]
> 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

> --
> Andrew Thompsonhttp://www.physci.org/
>
> Message posted via JavaKB.comhttp://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.