JApplet and JLayeredPane performance - Java Applet Development

Hello,
I'm having a really anoying issue using a JLayeredPane within an JApplet and its remove(Component c) method.
Here is my structure.
I've a JApplet that contains a JLayeredPane with two Component on two different zOrder. The first of them only contains a JLabel transparent aimed to handle clicks events unhandled by any control on the second Component. This second component contains 0...n JLabel showing our information. Those labels are positioned using relatives position on the Panel.
When I've to refresh the information shown I used to remove the Panel that contained all of them before recreating a new instance (as the JLabels aren't the same and even not on the same location) that will be added at the same zOrder layer.
The problem is; calling this JLayeredPane.remove(Component c) method takes up to 30sec when I'm running my applet within a browser (IE, FF, Chrome, Safari, Windows or Mac). Ok this could be anoying but fine when it wouldn't be an instanious call when I'm running the same JPanel / JLayeredSet within a JFrame or within an JApplet running on Linux computer using the OpenJDK !
I've already profiled my program trying to identifying a lock somewhere but it seems to be simply that the method is working...
What I'm looking for is any hint on what could cause this huge call time within an JApplet or whether it just impossible to replace a JFrame by a JApplet by simply using the same contentPane.
Please note that all the implemented interfaces on the JFrame are also implemented within the JApplet.
Any hint will be greatly appreciated :) 

Ciryatan wrote:
..this could be anoying but fine when it wouldn't be an instanious call when I'm running the same JPanel / JLayeredSet within a JFrame or within an JApplet running on Linux computer using the OpenJDK !Why does the applet have to be embedded? If there is no real reason, try launching the applet using [Java Web Start|http://www.java.com/en/download/faq/java_webstart.xml] *(<- link).*

Related

GUI class structure and heirarchy

When writing a GUI in java, what is the usual starting (extends) class ?
I've seen examples where the top class extends JFrame, whereas the SwingSet2 demo extends JPanel. Are there advantanges/disadvantages to these two ways ? Would there be any advantages/disadvantages to having the main window JFrame class below the class containing the main method, so that the "top" class is logically seperated from the GUI and its components ?
The SwingSet2 demo seems to be set up to run as an applet or as an application. Is this why it's extending JPanel ? Is it a good practice to (always) code a program so that it can be an applet or an application ?
Thanks,
Oscar Hobson 
there is no specific class that the GUI has to be built on
like there is for applets.
can be awt Frame or JFrame or JPanel or even JWindow you simply have to create the outer frame for the application to go in.
Swing components (lightweight) I guess are considered
better than more system integrated AWT(heavyweight)
Simplest approach is JFrame as outer container.
JPanels go inside JFrame. everything else goes inside a JPanel. JPanels can go inside of other JPanels
However you want to do that other thing (The main class)to make the most object oriented, reusable, components you can design is up to you.
As far as making your program work as an applet.
Only if you want to put it in a web page.
Desktop apps are way to complicated for that most of the time I think and most browsers only support early versions of java.
That's the way I look at it anyway.
That SwingSet2 example is a mind blower isn't it.
That would keep me up nights if I thought about it to much. 
there is no specific class that the GUI has to be built on
like there is for applets.
can be awt Frame or JFrame or JPanel or even JWindow you simply have to create the outer frame for the application to go in.
Swing components (lightweight) I guess are considered
better than more system integrated AWT(heavyweight)
Simplest approach is JFrame as outer container.
JPanels go inside JFrame. everything else goes inside a JPanel. JPanels can go inside of other JPanels
However you want to do that other thing (The main class)to make the most object oriented, reusable, components you can design is up to you.
As far as making your program work as an applet.
Only if you want to put it in a web page.
Desktop apps are way to complicated for that most of the time I think and most browsers only support early versions of java.
That's the way I look at it anyway.
That SwingSet2 example is a mind blower isn't it.
That would keep me up nights if I thought about it to much.
As you've seen in the Swing Set demo, the main reason for being careful about your 'starting point' is so you can be flexible about how your program is launched and where it is run.
The swing set demo can be easily run in an applet or an application; truly write once, run anywhere! If your main class extends JFrame then you're pretty much stuck.
However, an alternative design is to decouple the launch mechanism from the GUI itself; the GUI can be contained in anything that implements RootPaneContainer, such as JFrame, JApplet, etc. You can then have one class which extends JApplet if you want to run it in as a Java plug-in applet, and another which creates a JFrame host for your GUI.
I recently had to take this approach to the extreme where my main GUI is a JDesktopPane containing JInternalFrames which can be popped in and out of the desktop into their own JFrames! Making everything abstract enough to not care about the type of the parent window container (JInternalFrame/JFrame) was one hell of a job!

JFrames in Applets?

hi im trying to put Jframes in an applet.
this is the part i dont get.
public class Scores extends Applet
but i need to extend JFrames aswell which it wont allow me to do.
any help or suggestions would be most Appreciated 
You appear to be very very unclear on these concepts, which isn't bad, but means that you have your study cut out for you. I recommend:
1) that you go through as much of the Swing and Japplet tutorials that you can at the Sun tutorial site, and
2) Consider having your GUI code subclass JPanel and not JFrame or JApplet. As a JPanel the code could be used in an japplet or a jframe with ease and just a few lines of code.
Good luck. 
1) You're probably better of extendind JApplet, rather than the basic AWT Applet object.
2) JFrames represent independant windows on the client machine. Applet windows are not independant, they are controlled by the browser so your main window can't be both (though an applet can open JFrame windows, if the browser doesn't block them).
3) If you want to put child windows in your applet window, that's fine, but they aren't going to JFrame based. You should be able to set up a JDeskPane, for example, inside your applet window and put JInternalFrame windows in that. If the child windows are fixed then use JPanel objects.

JApplet in JDesktopPane

I have an applet that I want to put into a JInternalFrame to be used in a JDesktopPane. Is this possible? How can I achieve this?
The applet comes from another black box application that I want to be an inner application located in the JDesktopPane. 
seems at thought applet is a component i and 99% sure you could just add it to a JInternalFrame and then add that the JDesktopPane but i have not tried that before.
David 
An applet is just a panel, so you can put it in anywhere you want. You just create the applet, call init() and start(). However, the applet expects an applet stub and context, which you need to supply also, before calling init(). It's not too hard to write an implementation of both, but since it's a "black box" applet, you would probably need to provide something functional so it can get the real params and stuff. 
Are you familiar with xui? well I have an application that has a JDesktoppane but I want to use xui to create some JInternalframe to put in this pane. But xui creates an XApplet that extends JApplet. xui creates gui from xml. 
Okay then put the Applet into a JInternalFrame and put the internal frame into your desktop pane it is that simple.
Here's an idea, subclass JInternalFrame and let you applet object be a field in the internal frame so you can still call methods from it at all times and still have the internal frame functionality within you desktop pane
ICE 
But JApplet extends Applet which extends Panel....
Of course there is a problem... the applet would be heavyweight, wouldn't it... that would mean it would conflict with other Swing components. 
that means that there is no way to do what I want? 
Probably yes. But I must ask, do you think there is another solution to what you want to achieve without using the XUI toolkit?
If there is, then do your best to move your code AWT ie Applet, to say JPanel. This may not be as easy as abc, but it will save you the overhead of managing swing and awt component simultaneously
ICE 
Well as XUI is open source you have several options :-)
First off XUI doesn't do anything very special with the applet class so you could create a replacement pretty much by making a copy and replacing the applet specific parts. You would then need to take care of invoking the replacement so that the initialization sequence is similar to the applet case (calling the setup and initialize methods).
Secondly you could subclass the applet class and add customizations of the methods that deal withthe content pane. XUI adds a set on containers to the applet for the various elements in the frameset (or just one container if frames are not in use). Have a look at the XApplet.addTarget method.
The second method is probably the easiest and most maintainable. Let me know if you have any problems.

Swing Applet Repainting during moving window

Hi,
I've run into a problem with my swing JApplet. One of the elements of my GUI is a JLabel that contains a single Image. After the GUI is created, a seperate thread changes the image and prompts the JPanel containing the JLabel to repaint().
Now, this works perfectly with the AppletViewer using java 1.4.2.03. However, when I run the applet through Microsoft's Internet Explorer using Sun's VM 1.4.2.03 plugin, I notice a problem. If I take the window containing the applet and (assuming it is NOT maximized) move it around the screen, the JLabel's image will not always be drawn at the correct place. It will often overlap some of the other GUI elements.
I read something that Threads and Applets don't mix which suggested using the SwingUtilities.invokeLater() function, but I need this Thread to sleep() and didn't know how to make it do so because I never see the Thread class through the invokeLater() method.
It solves the problem if rather than have the JLabel repaint itself, I have the entire applet repaint itself, but this is not the ideal solution. Is there any way to determine when the window containing the applet is being moved and then force the applet to repaint itself entirely? Am I going about this wrong? Any help would be greatly appreciated!
Thanks,
B. Danny K.

JMainFrames and Java 3D Apps

Hi,
I have a swing application. The event associated with a particular JButton creates an instance of two classes. One is a Java3D application, which, as far as I can tell, has to extend the Applet class. In order to run the Java3D application in a non-applet/web context, it has to be passed to the constructor of the JMainFrame class. Everything about this works fine, except for the fact that, when the cross on the JMainFrame is clicked, the whole application shuts down, despite using the setDefaultClosingOperation() method.
Has anyone got any idea what's going wrong? JMainFrame extends JFrame, but is part of the COM packages (com.sun.j3d.utils.applet.JMainFrame). The annoying thing is that all other inherited methods seem to work fine! Here is the code I am using:
//This is the Java3D App - extending Applet
PointCloud thisCloud = new PointCloud(points, pointCount);
//This is the JMainFrame object which allows the applet to run as/in an application
JMainFrame pointCloud = new JMainFrame(thisCloud, 800, 600);
//All these inherited methods work, except the last one
pointCloud.setTitle("Point Cloud - " + fileNameBuffer);
pointCloud.setIconImage(new ImageIcon("heads.png").getImage());
pointCloud.setDefaultCloseOperation(JMainFrame.DO_NOTHING_ON_CLOSE);
I was going to then set a windowClosingEvent to deal with the act of closing the JMainFrame, but I can not get it NOT to close.
Incidentally, I posted this on the Swing forum, it may relate more closely to this forum. As such, can anyone suggest an alternative for running/launching a Java3D application from inside a Swing application, without needing the Java3D app to extend Applet? e.g. Could you add a Canvas3D object to any other type of Swing container? 
Hi,
Could you add a Canvas3D object to any other type of Swing container?yes you can. But since Canvas3D is a heavyweight component (subclass of java.awt.Canvas) you must consider some things when mixing heavyweight and lightweight components. (This is the same when using JMainFrame). There is a tutorial about this topic on the sun website, inside the swing area.
JMainFrame is a helper class to run an applet inside a frame as application. JMainFrame is actually not releated to J3D.
Cheers,
Oliver 
Yeah, sorry...i'm aware that JMainFrame isn't actually related to Java 3D as such, but I thought that someone might know the answer, given that Java 3D apps can be run as applets, JMainFrame being the class necessary to display them as/in proper applications.
Anyone got any further ideas on the original question - it's quite urgent! 
The Java3D Application is no need extends from Applet ( unless you want run your Java3D application on the browser).
I always use the JFrame instead of JMainFrame.
Simply using JFrame and jframe.getContentPane().add(canvas3D);
That's it.
If this solve your problem, do not forget give me the duck $. :-)
Thanks for the reply - how do you get the Java 3D app to initialise using JFrame - when extending Applet you use the init() method of Applet. What do you use for a JFrame? At the minute I am adding the canvas to a JFrame, and it won't display my 3D world.
Cheers,
James. 
Is is black or grey?
Black means your world is live and displaying.
Grey means canvas3D is not displayed or is not displaying anything. 
If your Canvas3D is grey you could change the background colour of it. (not to black though).
Then you can observe if the canvas is being painted or not. If you do not see the background colour of the canvas, you may have to check the LayoutManager used, to see if it sets the correct bounds of it. 
Thanks for the reply - how do you get the Java 3D app to initialise using JFrame - when extending Applet
you use the init() method of Applet. What do you use for a JFrame? At the minute I am adding the
canvas to a JFrame, and it won't display my 3D world.You are in application mode, not in the applet mode.
For application, you could initialize your application anywhere as you want, just make sure
the jframe.setVisible(true) is the last statement to be executed.
(This is the same as normal swing application)
Because once jframe.setVisible(true) it will start swing event-dispatch thread.
So init your application before starting of swing thread is good idea.
I change the java3D tutorial helloJava3D example by using JFrame instead of Applet, I do not have trouble.
(Suggestion: Try modify the tutorial by using JFrame first, if you success, then the problem is in your canvas3D scene graph problem; if it fail, then maybe take a look about how a normal swing application need to be, or I could post my HelloJava3D for you)

Categories

Resources