Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at sun.awt.Win32GraphicsEnvironment.displayChanged(Win32GraphicsEnvironment.java:109)
at sun.awt.windows.WToolkit$4.run(WToolkit.java:698)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)
14.10.2006 02:09:42 com.jme.app.BaseSimpleGame cleanup
public static void main(String[] args) {
SwitchDisplayMode test = new SwitchDisplayMode();
test.start();
}
}
i'm not sure how to understand it. is it a bug? am i doing something wrong? which thread is the one throwing the exception? did darkfrog add some secret multithreading? :P
the exception doens't occur when switching between windowed modes.
well i get this on my linux box when i press enter:
com.jme.system.JmeException: Bad display mode
at com.jme.system.lwjgl.LWJGLDisplaySystem.selectMode(LWJGLDisplaySystem.java:482)
at com.jme.system.lwjgl.LWJGLDisplaySystem.reinitDisplay(LWJGLDisplaySystem.java:461)
at com.jme.system.lwjgl.LWJGLDisplaySystem.recreateWindow(LWJGLDisplaySystem.java:247)
at de.pavel.forum.SwitchDisplayMode$1.performAction(SwitchDisplayMode.java:19)
at com.jme.input.ActionTrigger.performAction(ActionTrigger.java:264)
at com.jme.input.ActionTrigger$CommandTrigger.performAction(ActionTrigger.java:291)
at com.jme.input.InputHandler.processTriggers(InputHandler.java:376)
at com.jme.input.InputHandler.update(InputHandler.java:361)
at com.jme.app.BaseSimpleGame.update(BaseSimpleGame.java:186)
at com.jme.app.SimpleGame.update(SimpleGame.java:68)
at com.jme.app.BaseGame.start(BaseGame.java:66)
at de.pavel.forum.SwitchDisplayMode.main(SwitchDisplayMode.java:28)
when i change the call to display.recreateWindow(800, 600, 32, 60, true) to display.recreateWindow(800, 600, display.getBitDepth(), display.getFrequency(), true), it works.
@pavel jackoff: well the 800x600:32bpp@60Hz mode might not be supported on your system. but at least that problem is clear. i get (on win32) that problem when switching to any (valid) fullscreen mode.
@darkfrog: the test case extends simple game. how the hell does that method get called in the awt thread?
i might have ignored it if my system wouldn't have had hickups when that exception was thrown(i.e. sound was hanging). well i think i'll have to live with it until i upgrade my jdk/jre
Well, on many systems sound will hang if you change display resolution. So not sure if it's related to the exception (in fact I can't think of any reason why it would be).
the sound stutters for a few seconds ("hang" was the wrong word),which does not happen with (any) other apps on resolution change. i guess i'll leave it this way for a while and return to it later.
Ah, well it's a known issue with some videocard/driver/chipset combinations.
But if it doesn't happen with other applications I guess your combination is fine. Still, don't see how an exception can cause that. It's not like throwing an exception slows you down more than a few nanoseconds.
@darkfrog: the test case extends simple game. how the hell does that method get called in the awt thread?
According to the stack you posted, it does indeed get handled in the awt event queue.
sfera said:
i get this:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
at sun.awt.Win32GraphicsEnvironment.displayChanged(Win32GraphicsEnvironment.java:109)
at sun.awt.windows.WToolkit$4.run(WToolkit.java:698)
Probably something inside lwjgl itself related to switching display modes though.
Pavel, your issue is known... Linux and Mac usually have to have 0 passed in for frequency in order to work.
@renanse: check the link llama provided. it's a konwn bug for pre 1.6 jvm's. it's (almost) fixed in 1.6beta2 and has nothing to do with jme/lwjgl/darkfrog's secret multithreading XD
@llama: maybe it depends on how many times the exception is caught/rethrown and handled (and how much time the handling/recovery takes). whatever. there's no point in thinking about problems i can't solve.
Just for kicks why don't you try what Renanse and I have been suggesting and push the invocation into the OpenGL thread and see if that doesn't resolve it magically?
@frog: Dude, look at his 5 line program. There's no threads! RTFT :roll:
@sfera: the stacktrace shows it's just a simple NPE that's thrown. Even if Sun for some reason did not use nested exceptions if you look at the stacktrace it's very unlikely that there's anything seriously bad going on. And it's only thrown once here.
@llama look at the stack trace, it's occurring in the AWT-Event-Queue. You know, that thread that you don't necessarily want but gets created for you when you using AWT/Swing?
Look back at the code, it's in the actionPerformed that it's occurring. The event handling occurs when something gets invoked in the AWT thread and kicks off the listeners actionPerformed methods so it's NOT in the OpenGL thread, it's in the AWT-Event-Queue…
Yes it is. Hello. I posted the link to the bug even.
That doesn't mean sfera does anything to cause it. Check the number of running java threads running in any of your programs (espc. as soon as you touch anything Swing/AWT related). You didn't make those threads, you don't even use them half of the time. But surprisingly, the code that does run in those threads is made by normal people just like you and me. Some might even have animal nicknames and what not. And yes, their code too has bugs. Like this one.
I won't claim to be an expert on jME's input system but I certainly hope that it's all done in the jME thread or in any case not in the AWT thread (because… why? why would it do that?)
Okay, so you're right…I was missing something. For some reason every time I looked at that code I was seeing an AWT actionPerformed instead of the jME Action.
You could have reproached me in a less jerk-like way though.