I've been working on a game that's played in a java applet. It all works fine, until you try to refresh the page. It often seems to 'keep' the applet it used so far, and relaunches the game in the same applet. A new process is not created, and the ram usage shoots up (~250mb instead of ~140mb), and the same console is used for the applet. The drawing process is also quite laggy; it often skips about 0.5 seconds of frames before drawing again.
It only sometimes completely refreshes the applet; a new process is created (as seen in Windows' task manager), a new console opens, it uses less ram; it just starts from scratch again.
As I experience issues when it reuses the applet, I would like to force it to create the new process every time I refresh. Is there a way to do that? Or can I somehow fix the issues when it doesn't completely refresh?
The game I'm working on can be seen at http://patrickdev.nl/galaxy048/. Once it runs, press 'f' to toggle the fps and memory details.
Thank you in advance.
Applets support a parameter that force it to run the applet in a new jvm. This also works after refreshing the page, and is exactly what I was looking for - it starts from scratch. Just add this parameter to your applet tag:
<param name="separate_jvm" value="true" />
More information at http://www.oracle.com/technetwork/java/javase/plugin2-142482.html#SEPARATE_JVM
Related
Java programs start slowly.
I program a JavaFX desktop software. When I double click the executable jar, it costs nearly 5 seconds to show the window. I think the JVM spends a little time to load the class.
But when I open Eclipse, the progress GUI is showed immediately. How can I do that like Eclipse? Does it use other technology to show the GUI without JVM?
The 'eclipse' executable is actually a small C program (source code is here).
This reads the eclipse.ini, displays the splash screen if it is specified and then initializes the JVM using the parameters specified in the eclipse.ini and starts the main Eclipse Java code. So the JVM initialization and Java startup is done with the splash screen already displayed.
The Java code is given a reference to the splash window so it can update the progress and close the window when done.
If you write an Eclipse RCP the same code is used to start your RCP.
The secret is: which classes are used to display that "splash screen"?!
Guessing here: the eclipse people have fine-tuned that code. It might be possible that they use AWT only components there. Well, I stay corrected: they are not using java at all for the splash screen (see the other answer). No surprise.
Beyond that, anecdotal answer on splashing with Java: many years ago I wrote a Swing application. Of course, the customer wanted a nice splash screen, with the company logo and a progress bar; showing the amount of loaded "modules". I coded the first version using swing panels. That panel came up after 15 seconds (no SSDs back then), and 3 seconds later, 100% were reached. Solution back then: I wrote a new version that went with a minimal number of AWT components. In the end, that splash screen looked a little bid "less nice" - but it came up after say 3, 5 seconds.
I think I even tampered with class loading order to ensure that all "expensive" classes were loaded after I pulled the stuff required to show the splash screen.
( and in case this doesn't result in "enough delay" between "splash showing up" and "application fully loaded" ... one could simply extend the "life time" of the splash screen by simply having it sit there a bit longer. sure, you don't tell the customer about that ;-)
I have a legacy Java application that uses Java 1.3
It works fine on windows Xp but now I need to make it run on windows 7.
I have installed the 1.3 jdk however when it first loads, the app won't render properly. Bits of the screen just show grey background, selecting buttons won't load a new screen etc.
I do know watching the output from the app it just purely graphics not rendering properly.
However if I press "Ctrl-alt-delete" and then just press "cancel" the software runs perfectly.
If I have a second monitor plugged in, it runs perfectly.
Has anyone got any suggestions how to make app run perfectly first time.
Thanks
Firstly, update your java, no excuses not to.
You can try the hack of resizing your component to a different size and then back again. I find this is the best way to make sure that swing doesn't do this sort of mischief with black squares here and there.
These things happen from time to time with non native tools for desktop development as opposed to those specifically designed for the targeted platform.
I have developed a java program that runs fine in Mac OS X (10.6.7).
But if I click on another window such as Finder or another application, my program freezes, or the graphics are not updated anymore. If I click on my program again the graphics are updated again and runs well.
Does anyone know what that can be?
I coded it with the LWJGL and slick libraries.
Thanks!
Taken from here:
By default slick will not render anything if it does not have focus,
so good practice for applets is to set
container.setAlwaysRender(true);
so that it always renders even when it doesn't have focus.
This seems to refer to GameContainer.setAlwaysRender. Although the forum post talks about applet, both AppGameContainer (standalone-application) and AppletGameContainer.Container extend from it.
I'm working on a Java program that is intended to run in full-screen mode. It uses numerous of customized Swing components and Java2D-drawn components that need to be updated and repainted several times a second. And it was working relatively fine on my underpowered work PC.
But then I tried it out at home on my much more powerful PC. And it ran noticeably slower. Triggering an event that should have instantly updated about 20 different screen elements instead caused an effect where each element seemed to take at least a quarter second each to repaint itself. So instead of instantaneous changes it was taking 5 seconds to complete each screen change.
I thought that maybe I was trying to repaint too often or in the wrong manner. But after experimenting a bit with other ideas, on a hunch I let the application start up in a windowed mode instead of in full-screen mode. And with that one change, everything started to work perfectly fast and smooth.
So I suppose there are really two issues here: Why does full-screen mode cause this problem? And why is it only causing this problem on my faster computer? I do suspect there's an OS-related bug. My slow work computer is Windows XP while the home one is Windows 7. I saw in other threads that Aero on Win7 can cause Java speed issues so I tried disabling it. That did cause a small speed improvement but it still wasn't as smooth as when I ran in windowed mode. Has anyone else had performance issues running full-screen Java apps on Win7? And if so, is there a work around?
I found the solution. I stumbled upon Oracle's Java System properties page (http://docs.oracle.com/javase/1.5.0/docs/guide/2d/flags.html) and figured there might be something useful there. While using the trace command I noticed that there were a lot of Direct3D references. Since nothing in my app is 3D, I thought that strange. So I added -Dsun.java2d.d3d=false to my Java command line. As the page says that option will "turn off the Java 2D system's use of Direct3D". And it worked like a charm. Now it runs perfectly smoothly on my Windows 7 machine in full screen mode.
We have a java applet that runs windowed outside the browser window. I always assumed that by clicking the X to close the window (or right clicking on the task bar and selecting close) was all you needed to do to close an applet.
However, it turns out that when closed this way, our applet crashes Safari (in both Mac and Windows) every time.
Is there something I am supposed to be doing in the code when an applet closes? The first culprit that comes to mind in the code is a class/library that does a socketed connection for Jabber/XMPP.
Use the destroy() life cycle callback in your applet to dispose of all resources that you have open (threads, sockets etc). What happens if you don't might vary per browser, but in my experience (mainly Firefox) threads usually keep running, forcing a restart of the browser in order to reload your app. Not slick. I haven't seen a crash due to this, but disposing of resources is a good practice anyway.