Hi everyone!
I’m currently trying to use jME for an applet. I’ve already run some tests: Get a jME applet running, use the jME canvas in a dialog window, load models from the server and display them. All of this worked fine and displayed at a smooth framerate of 340 FPS…until I tried to run it on a notebook.
The average framerate there is not the problem (~100 FPS), but there seems to be problem with the input system. As long as I don’t move the mouse inside the jME dialog window or the main applet window, the applet runs smoothly. But as soon as I move the mouse just one pixel inside the jME dialog or the applet window, the display lags for about 3-5 seconds.
I did some testing with 2 normal desktop computers and 2 notebooks, which all use the same JRE (1.6). The hardware setup of the machines shouldn’t be the problem: One of the desktops was an Athlon XP 2000 with a GF 4 graphics card, and it had no problems displaying the applet, while the notebooks had better hardware and still showed the choppy behavior.
As the 3D window also lags when I move the mouse inside the main applet window, I suppose the problem originates from the the AWT input system used in the applet. I tried using the LWJGL input system instead, but found out that this can’t be used in applets at all (this was confirmed by the applet guide, which I should have read before -.-).
Has anyone else ever stumbled upon that problem and maybe found a reason (and maybe a solution 
)?
EDIT: I’ve also tested the applet with different browsers, and Firefox, Opera and IE all show the same lags. And one more note: The 3D display also lags when I move the mouse inside other java windows, e.g. the Java console in Firefox…
Do you have it up somewhere we could see? When I run our examples such as jmetest.awt.applet.AppletTestBoxColor I do not see such lag…
Update:
I did some research on this and found out that indeed the use of org.lwjgl.opengl.AWTGLCanvas together with AWT inputs seems to be what causes all the trouble.
In AWTGLCanvas (and com.jmex.awt.lwjgl.LWJGLCanvas, which extends it) the updating and rendering is performed by the AWT event queue. The queue receives events when repaint is called on a Component and if any input action is performed (e.g. mouse movement). If the queue can't perform updates for the event instantly (e.g. if the CPU is busy serving some other thread or executing a costly event), the events are stacked and processed in one batch later. So, if there are a lot of mouse events coming in while the CPU is busy and get stored, the rendering is paused while the mouse events are being processed.
I found a "dirty" workaround for this:
a) Use longer update intervals for the updater thread and
b) set a higher thread priority for the AWT event queue.
The result is that the maximum framerate drops a bit, as a consequence of the longer update intervals and the fact that the AWT event queue receives more CPU time. However, there are almost no "event batches" anymore, and therefore significantly less hang-ups. In the app I'm writing the 3D part for, this may be even less of an issue, as the app doesn't require continuous updating but only updates when the scene is being changed by events.
@renanse: Check your PMs
Hmm, ok, I can't make it happen still, but sounds like something to keep an eye out for.
By the way, here’s a thread in the LWJGL forum where someone else encountered that problem: [link].
This thread gave me the idea about the event queue issue, and after trying a higher priority for the event queue, I think that idea is not too wrong.
One more idea from the thread (and the thread about JOGL linked from it) is that maybe there are several 3D updates executed for a single event. If I can find the time to find out where mouse events arrive in a jME applet, I could check on that…
I can confirm that behaviour to.
Under some circumstances you can get multiple events of same type in one frame. I extended an evenhandler and filtererd duplicates that came in.
If you install the latest JRE on that notebook, and make sure your Java plug-in uses that JRE, does the problem go away?
I just upgraded from JRE 1.6.0 update 1 to update 3 on my notebook, and… nothing changed. Still the same choppy behavior.
I also did some more testing and ran the applet on a desktop PC with an Athlon c @ 1.333 GHz, GF 4 graphics card, JRE 1.6.0 update 3. That system was so slow that the average framerate was as low as 20 FPS! But still, no problems with mouse movement, no hang-ups…
Could the Pentium M, which was installed in all notebooks I tested on, be the problem?
One more preformance test: On a notebook with an Intel Core2Duo T7500 @ 2.2 GHz the rendering worked fine, without any lags…
I ran into this problem too. Maybe it's because of my lack of jME, LWJGL and/or AWT knowledge, but I'm not sure how to implement the proposed solutions:
- I'd like to keep using the SimpleJMEApplet for now. Should I overwrite the InputHandler to filter duplicate events? If I want to keep the existing handler, can I wrap this handler?
- Where and how do I specify the update interval and thread priorities?
Thanks a lot!
Hi pbackx! First of all, welcome to the jME community!
Almost forgot about this topic, but as you're bringing this up: I noticed some things concerning the choppy behaviour in Applets on Notebooks lately. When I activated multisampling (DisplaySystem.getDisplaySystem().setMinSamples(4)), the rendering didn't chop up any more. Don't really have any clue as to why that is, but maybe it will help you.
However, be aware that some older graphics hardware apparently has problems with multisampling under Windows. When I tested on an ATI Radeon Mobility 9000 or a NVIDIA GeForce 4 MX 440, for example, the rendering was unable to start as long as the minimum AA samples were > 0. This is also mentioned in the Javadoc of the LWJGL PixelFormat (org.lwjgl.opengl.PixelFormat):
WARNING: Some pixel formats are known to cause troubles on certain buggy drivers. Example: Under Windows, specifying samples != 0 will enable the ARB pixel format selection path, which could trigger a crash.
I've been able to solve this problem by waiting for a few seconds (~5) after making the 3D Canvas visible, then checking if the rendering had been started and, if not, re-initializing the DisplaySystem and Canvas with minSamples = 0.
Concerning your questions:
- Overwriting the default InputHandler seems unnecessary - I used it with my applet and didn't have any problems with it.
- The update Interval in SimpleJMEApplet is defined by the (protected) field repaintSleepTime, so you can easily change it in derived classes. The Thread priority can be set by using the setPriority(int) method of Thread. The possible values to pass to this method range from Thread.MIN_PRIORITY to Thread.MAX_PRIORITY.
LWJGL 2.0 supports embedding a display inside an AWT window without a canvas, which will use the native input handling instead of AWT's input. I might make an extension to jME-context to support this feature…
Thanks for the answers.
I finally had a little time to experiment. FYI, I'm seeing this issue on an IBM ThinkPad T42 laptop with an ATI Mobility Radeon 7500. Certainly not the state-of-the-art, but I'd like to make it accessible for every one.
The only thing that clearly made a difference is the repaintSleepTime. If I put that on 10 or even 20 the application only hangs when changing the browser window (scrolling, resizing), otherwise it seems to work nicely.
Multisampling didn't do much, it did work, it just didn't really seem to improve things.
Same story with changing the thread priority.
I also tried using an empty InputHandler, which, again, didn't do much. The behavior was still the same. But if I understood the code correct, componentResized events (which I think are the ones giving me the most troubles) are handled by the SimpleJMEApplet and I can't easily handle those myself. Unless I roll my own SimpleJMEApplet. Which I've put on my someday list 
For now, the applet is working acceptable, as long as the user doesn't resize every few seconds.
Regards and thanks again!
Hi pbackx. I am using a T41 with similar ATI graphics and I am having similar problems; my animation and the FPS counter freeze on a mouseover. Could you possibly post your solution? TIA
quakedeus said:
Hi pbackx. I am using a T41 with similar ATI graphics and I am having similar problems; my animation and the FPS counter freeze on a mouseover. Could you possibly post your solution? TIA
I didn't really find a good solution. The problem solved itself when I upgraded my laptop. I've heard few people complain about it, so I think it's only related to certain types of hardware and/or drivers.
Have you tried the latest JDK? It has a bunch of optimizations for applets that might help.
Regards,
Peter
Thanks for the update. I made a small improvement with "this.repaintSleepTime = 20". I do have the latest JDK but have not tried my applet on a more capable machine. I will try this next. Thanks for the feedback.
Hi pbackx. I tested my applet on my work laptop, a Dell Latitude D600, and the results confirm your last observation; the applet works great, flawlessly, on the D600! Just in case it may help someone else here are the differences between the video card in the IBM T41 and the Dell D600.
IBM T41:
ATI MOBILITY RADEON 7500
PNP Device ID PCIVEN_1002&DEV_4C57&SUBSYS_05301014&REV_004&1BFA44D4&0&0008
Adapter Type ATI MOBILITY RADEON 7500 AGP (0x4C57), ATI Technologies Inc. compatible
Adapter Description ATI MOBILITY RADEON 7500
Adapter RAM 32.00 MB (33,554,432 bytes)
Installed Drivers ati2dvag.dll
Driver Version 6.14.10.6547
INF File oem63.inf (BR_43099_ati2mtag_M7 section)
Color Planes 1
Color Table Entries 4294967296
Resolution 1024 x 768 x 60 hertz
Dell D600:
MOBILITY RADEON 9000
PNP Device ID PCIVEN_1002&DEV_4C66&SUBSYS_011D1028&REV_024&1BFA44D4&0&0008
Adapter Type MOBILITY RADEON 9000 AGP (0x4C66), ATI Technologies Inc. compatible
Adapter Description MOBILITY RADEON 9000
Adapter RAM 32.00 MB (33,554,432 bytes)
Installed Drivers ati2dvag.dll
Driver Version 6.14.10.6458
INF File oem1.inf (ati2mtag_M9 section)
Color Planes 1
Color Table Entries 4294967296
Resolution 1024 x 768 x 60 hertz