AWTGLCanvas and context

Started by Pogomon, January 06, 2006, 12:03:17

Previous topic - Next topic

renanse

elias, I noticed there was still some discussion on this topic in the irc logs.  Was there a test or something you were looking for from me?  One way to reproduce it (but it seems to only be on windows, I can't get my Mac to complain in the same way) is to pull up jME's tests.  Open the source for jmetest.effects.RenParticleEditor and add the following method to the inner class MyImplementor (so like around line 1840):

int x = 0;
public void simpleRender() {
    if (x++ == 1000) throw new NullPointerException("ack!");
}


When you run on the PC, it kicks off the NPE after a few seconds and then immediately floods stderr with IllegalStateExceptions like the one I posted previously.  (of course, I'm still running .99)

Hope that is of some help to you.  When I get to work tomorrow morning I'll try out the new lwjgl release.

renanse

So, I just updated to 1.0b and now when I run our awt based apps I get a native stack dump after the first rendering completes (so I see a glimpse of the app, then it crashes.)  If I comment out all of the rendering calls and the camera calls to glViewport, it can run and show off the background color (um, yay?)   Any ideas?  The stack is not very helpful:


#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00add6df, pid=1520, tid=4804
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing)
# Problematic frame:
# j  org.lwjgl.opengl.GL11.glViewport(IIII)V+0


I can run the awt tests in lwjgl_test, but honestly they aren't all that complex. :)

renanse

More information...  The app I am working with has various swing components to the right (see RenParticleEditor)   If I don't touch them, the scene comes up and displays fine.  As soon as I make changes (such as setting the text on a label) it bombs.

elias

Can you post a minimal test program that crashes? Preferably with as little Swing/AWT code as possible. Actually, try avoiding Swing altogether for testing purpose. Did you try disabling ddraw with the java2d switch (can't remember it's name).

EDIT: I also need the OS and graphics card model.

- elias

elias

Actually, that crash trace reminds of the JVM bug that lwjgl triggers with the large ContextCapabilities instances ((http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6342951). It is fixed in 1.5.0_07 apparently, so could you try that? Alternatively, try this before the crashing GL call (GL11.glViewport()):

if (GLContext.getCapabilities() == null)
throw new IllegalStateException("No context current!");


- elias

renanse

I'll try those on my PC at work once I get there.  From home on my mac with the same code I am getting an NPE:

Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
	at org.lwjgl.opengl.GL11.glViewport(GL11.java:2725)
	at com.jme.renderer.lwjgl.LWJGLCamera.onViewPortChange(LWJGLCamera.java:167)
	at com.jme.renderer.lwjgl.LWJGLCamera.resize(LWJGLCamera.java:112)
	at com.jme.renderer.lwjgl.LWJGLRenderer.reinit(LWJGLRenderer.java:205)
	at com.jmex.awt.JMECanvasImplementor.resizeCanvas(JMECanvasImplementor.java:72)


The app still draws after that but flickers like mad.  Any attempt to resize the window (and thus call the above code again) also throws the error but continues working.  Dunno if that is a clue.  I don't have the source at the moment to see what 2725 is... perhaps the caps you mentioned?

elias

I suspect your work machine has an upgraded JVM. The problem is that the application does GL rendering outside of paintGL() which is not allowed for AWTGLCanvas.

- elias

renanse

Ok, although the vms are actually both 1.5.0_06

renanse

The issue was calling GLContext.getCapabilities(); outside of paintGL.  I can see the reasoning behind the problem, but why did it suddenly become apparent with 1.0b?

elias

Because the workaround is releasing the context after each paintGL(). The previous version let the context stay current.

- elias

Evil-Devil

Quote from: "elias"Because the workaround is releasing the context after each paintGL(). The previous version let the context stay current.

- elias
That was good - in my opinion. All my applications worked with that ...

renanse

Yeah, my main code works now (all gl calls, no matter what are in paintGL) BUT I still get errors like the following if I display dialogs in my app:

java.lang.NullPointerException
	at org.lwjgl.opengl.GL11.glClear(GL11.java:576)
	at com.jme.renderer.lwjgl.LWJGLRenderer.clearColorBuffer(LWJGLRenderer.java:449)
	at com.jme.renderer.lwjgl.LWJGLRenderer.clearBuffers(LWJGLRenderer.java:474)
	at com.nccore.tools.jemviewer.view.JEMViewImplementor.doRender(JEMViewImplementor.java:425)
	at com.jmex.awt.lwjgl.LWJGLCanvas.paintGL(LWJGLCanvas.java:86)
	at org.lwjgl.opengl.AWTGLCanvas.paint(AWTGLCanvas.java:279)
	at sun.awt.RepaintArea.paintComponent(Unknown Source)
	at sun.awt.RepaintArea.paint(Unknown Source)
	at sun.awt.windows.WComponentPeer.handleEvent(Unknown Source)
	at java.awt.Component.dispatchEventImpl(Unknown Source)
	at java.awt.Component.dispatchEvent(Unknown Source)
	at java.awt.EventQueue.dispatchEvent(Unknown Source)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
	at java.awt.EventDispatchThread.run(Unknown Source)


I can get around that if I put it in a SwingUtilities.invokeLater, but man...  

Is it possible to instead of always releasing the context, simply check at the beginning if we already have the context and if so, skip regrabbing the context?  Seems like that would lower overhead as well...

Evil-Devil

Why not checking for releasing and setting the context in AWT Application by yourself like in 0.99? That was fine exspecially when using FileChoosers for loading different file i.e. Models

elias

Evil-Devil: Because you can't force another thread to release the context.

- elias

renanse

Can we block until the other thread releases the context?