AWT exception when switching fullscreen display modes

Troubleshooting General Help
1

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


when running this:


import com.jme.app.SimpleGame;
import com.jme.input.KeyInput;
import com.jme.input.action.InputAction;
import com.jme.input.action.InputActionEvent;

public class SwitchDisplayMode extends SimpleGame {

  @Override
  protected void simpleInitGame() {
    InputAction switchAction = new InputAction() {

      @Override
      public void performAction(InputActionEvent evt) {
        display.recreateWindow(800,  600, 32, 60, true);
      }
     
    };
    input.addAction(switchAction, "blah", KeyInput.KEY_RETURN, false);
  }

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

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

You need to call the recreate inside the OpenGL thread. It looks like that is being done in the AWT thread.

4

@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?



could anyone confirm this issue?

5

Got it here too.



Looks like a Swing bug to me. Fixed for 1.6?



http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6358034

6

so the answer is "please upgrade your jre/jdk". doh! this sucks.  :x

7

Well, my answer would be just ignore it.

8

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

9

oh, and thanks for yor help llama :wink: (i always forget this part)  ://

10

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

11

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.

12

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.

13
sfera said:

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

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

15

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? :wink:

16

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

17

@renanse: while 0 does work, so does 85. my system simply doesn't allow the frequency or bitdepth to be changed.

18

@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?  :stuck_out_tongue:



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…



Am I missing something?

19

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?)

20

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.