NativeWindowException: Unable to lock surface

I'm getting some odd behavior after updating java to 1.7. Any JOGL apps inside my OSGi (SWT using the AWT_SWT bridge with the AWT GLCanvas) application will only work correctly on my primary display. If I move them to my secondary display they tear off a window titled "JavaEmbeddedFrame" which stays on the main display. If I attempt to move that window to the secondary display it eventually throws a NativeWindowException. Also, it will sometimes stop displaying my 3D scene correctly by only displaying content during animation and just the component's background color when not animating.

I have an AMD Radeon 7950 running Ubuntu 13.04. My co-worker that uses Ubuntu 12.04 with an nVidia card with the same issues but another co-worker with debian and an nVidia card has no issues. No issues on our Windows machines, either. No issues under Java 1.6.

Anyone have any ideas why I'm getting these issues? Could it just be a configuration issue? I tried the newest version of JOGL (lots of API changes, yay!) but still the same issues. Our JOGL applications not using the AWT_SWT bridge don't have issues.

Get this output when application starts

libEGL warning: DRI2: failed to authenticate

and stops

X11Util.Display: Shutdown (close open / pending Displays: false, open (no close attempt): 1/1, pending (not closed, marked uncloseable): 2)
X11Util: Open X11 Display Connections: 1
X11Util: Open[0]: NamedX11Display[:0, 0x7fd9c43200c0, refCount 1, unCloseable true]
X11Util: Pending X11 Display Connections: 2
X11Util: Pending[0]: NamedX11Display[:0, 0x7fd9cc196bb0, refCount 0, unCloseable true]
X11Util: Pending[1]: NamedX11Display[:0, 0x7fd998000e10, refCount 0, unCloseable true]

Getting the following exception when trying to maximize the screen.

Caused by: javax.media.nativewindow.NativeWindowException: Unable to lock surface
	at jogamp.nativewindow.jawt.x11.X11JAWTWindow.lockSurfaceImpl(X11JAWTWindow.java:85)
	at com.jogamp.nativewindow.awt.JAWTWindow.lockSurface(JAWTWindow.java:314)
	at jogamp.opengl.GLDrawableImpl.lockSurface(GLDrawableImpl.java:236)
	at jogamp.opengl.GLDrawableImpl.setRealized(GLDrawableImpl.java:156)
	at javax.media.opengl.awt.GLCanvas$2.run(GLCanvas.java:577)
	at jogamp.common.awt.AWTEDTExecutor.invoke(AWTEDTExecutor.java:49)
	at javax.media.opengl.awt.GLCanvas.validateGLDrawable(GLCanvas.java:563)
	at javax.media.opengl.awt.GLCanvas.access$500(GLCanvas.java:141)
	at javax.media.opengl.awt.GLCanvas$9.run(GLCanvas.java:963)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:241)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:727)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:688)
	at java.awt.EventQueue$3.run(EventQueue.java:686)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:697)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Hi

Please try to reproduce your bug on a very small test case and write a bug report with all your indications (especially the version number of each driver). However, maybe there is something wrong with this AWT_SWT bridge, try to use NewtCanvasSWT or com.jogamp.opengl.swt.GLCanvas.

I wrote up a small test case using just jogl, swt, and java (none of our jogl-based libraries) as well as tested the swt.GLCanvas variant (same issues).

I have a Gigabyte Radeon 7970 GHz Edition (not 7950 as previously stated) with fglrx-updates version 9.012 and have tried with java 6 and 7 (same issue).

Not sure how to post my source to the forum so I'll put up a bug report and link to it here.

https://jogamp.org/bugzilla/show_bug.cgi?id=739

You should try NewtCanvasSWT, we have much more control on it. The flickering can be reduced by using sun.awt.noerasebackground.

sun.awt.noerasebackground didn't fix the issue with the original test. I also created a NewtCanvasSWT/GLWindow test application and had the same issue but with the following fatal error when closing the application:

Warning: NEWT X11 DisplayDispatch 0x7f098078c4f0, Couldn't handle event 17 for X11 window 0x3c00002
X11Util.Display: Shutdown (JVM shutdown: true, open (no close attempt): 2/2, reusable (open, marked uncloseable): 1, pending (open in creation order): 3)
X11Util: Open X11 Display Connections: 2
X11Util: Open[0]: NamedX11Display[:0, 0x7f098078c4f0, refCount 1, unCloseable true]
X11Util: Open[1]: NamedX11Display[:0, 0x7f09805bb340, refCount 1, unCloseable true]
Nativewindow X11 IOError: Display 0x7f098078c4f0 (:0): Resource temporarily unavailable
Nativewindow X11 IOError: Display 0x7f098078c4f0 (:0): Resource temporarily unavailable
FATAL ERROR in native method: Nativewindow X11 IOError: Display 0x7f098078c4f0 (:0): Resource temporarily unavailable
	at jogamp.newt.driver.x11.DisplayDriver.DispatchMessages0(Native Method)
	at jogamp.newt.driver.x11.DisplayDriver.dispatchMessagesNative(DisplayDriver.java:106)
	at jogamp.newt.DisplayImpl.dispatchMessages(DisplayImpl.java:442)
	at com.jogamp.newt.swt.SWTEDTUtil$1.run(SWTEDTUtil.java:57)
	at com.jogamp.newt.swt.SWTEDTUtil$NewtEventDispatchThread.run(SWTEDTUtil.java:239)

Can you reproduce your bug without JOGL? I suspect that something wouldn't work even with plain SWT + AWT. For example, use a plain java.awt.Canvas instead of a GLCanvas.

I made a quick demo by creating a Canvas in place of the GLCanvas and updating the fill color every 5-10 milliseconds. It doesn't have the same issues (no NativeWindowExceptions) but it does have issues filling a solid color (it sometimes has white blocks looking like coarse static).

Thanks for posting the SWT bug for multiple monitors on the bug report I posted for JOGL; for those seeing this here, this is the link:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=372560

Though, I'm using the most recent version of SWT (that bug states resolved as of last august) and even so, the error message occurs only when I close the application; the issues stated happen well before that (resizing the frame, moving to secondary screen and maximizing the window). It still could be an SWT/GTK issue but I have no idea.

If I disable one of my displays the flickering issue still occurs but the JavaEmbeddedFrame only disconnects when moving the application to the secondary display and maximizing it.


Thanks for the response.

sranger wrote

I made a quick demo by creating a Canvas in place of the GLCanvas and updating the fill color every 5-10 milliseconds. It doesn't have the same issues (no NativeWindowExceptions) but it does have issues filling a solid color (it sometimes has white blocks looking like coarse static).

Then, you should write a bug report against SWT with this simple java.awt.Canvas as this part of your bug doesn't concern JOGL.

sranger wrote

Thanks for posting the SWT bug for multiple monitors on the bug report I posted for JOGL; for those seeing this here, this is the link:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=372560

Though, I'm using the most recent version of SWT (that bug states resolved as of last august) and even so, the error message occurs only when I close the application; the issues stated happen well before that (resizing the frame, moving to secondary screen and maximizing the window). It still could be an SWT/GTK issue but I have no idea.

If I disable one of my displays the flickering issue still occurs but the JavaEmbeddedFrame only disconnects when moving the application to the secondary display and maximizing it.

I think that there might be a similar bug, not exactly the same. Please can you compare the version number of GTK on the different machines you used? Does the problem with the embedded frame occur with a plan AWT Canvas too?

sranger wrote

Thanks for the response.

You're welcome.

The repaint issue with the white blotches happens with a AWT Frame/Canvas but the JavaEmbeddedFrame issue does not. With a JFrame/JPanel neither issue seems to occur.

It looks like I have gtk 2.24.17-0ubuntu2 installed as well as gtk 3.6.4-0ubuntu8 and the other machine we've had issues on has gtk 2.24.10-0ubuntu6 with 3.4.2-0ubuntu0.5. The linux guy not having an issue is using Debian with KDE/Qt so it does look like a Gtk related issue.

Hi,

I've reproduced same bug you described with JDK1.7 on Linux, you can read my post here.
This is not a JOGL bug but, in my opinion, a JDK bug. I've filed 2 bug reports:
Oracle: http://bugs.sun.com/view_bug.do?bug_id=8006421
Eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=397985

I encourage you to complete, add test case, vote for these bugs.
Maybe, they will restore the old behavior (JDK 1.6) maybe not!
While waiting for their decision, I replaced the AWT GLCanvas by a NewtCanvasAWT and now I'm doing some tests with a NewtCanvasSWT in a RCP app.
On this point, where can I find some tutorials/demos/doc for NewtCanvasSWT?

Thanks,
Celine

Hi Céline

You can do this:

Display display = new Display();
Shell shell = new Shell(display);
shell.setLayout(new FillLayout());
Composite composite = new Composite(shell, SWT.BORDER);
GLWindow window = GLWindow.create(capabilities);
NewtCanvasSWT canvas = new NewtCanvasSWT(composite, SWT.NO_BACKGROUND, window);
window.addGLEventListener(new MyPrettyGLEventListener());
shell.setSize(300, 200);
shell.open();

I'm very interested in your feedback about NewtCanvasSWT in an Eclipse RCP application. Let us know whether something goes wrong.

Moreover, I think that the previous behaviour won't be restored but there's a way to fix that in OpenJDK 1.7, the graphics configuration picked up when you go to another monitor should be as capable as the previous one if possible.

If you use NEWT, it will be easier for us to ensure it just works even though SWT support wasn't the top 1 priority.

ok, thanks.
In fact I'm expected to a more technical doc, particularly about NEWT threading.
As far as I see, the SWT UI thread is used.

I had the problem with display.async method but I found the bug report #643 and updated my JOGL version to 2.0.2.
Now I have a problem when the editor is detached from the main RCP app window to its own window, the 3D scene is not rendered on Windows. I have to do some tests on Linux too.
I'll keep you informed.

Celine wrote

ok, thanks.
In fact I'm expected to a more technical doc, particularly about NEWT threading.
As far as I see, the SWT UI thread is used.

Maybe Sven has some documentation to suggest, I have only found this document.

Celine wrote

I had the problem with display.async method but I found the bug report #643 and updated my JOGL version to 2.0.2.
Now I have a problem when the editor is detached from the main RCP app window to its own window, the 3D scene is not rendered on Windows. I have to do some tests on Linux too.
I'll keep you informed.

Maybe the OpenGL context is destroyed during the detachment but it's the typical kind of problem Newt canvases are intended to solve.

FYI, I've just found a bug report for GLCanvas/JDK 1.7/Eclipse RCP problem:
https://jogamp.org/bugzilla/show_bug.cgi?id=712

For my Eclipse RCP/NewtCanvasSWT problem, I will file a bug report.
The OpenGL context is not destroyed, in fact, the NewtCanvasSWT handle a resize event with a height value = 0, hence the window is marked as invisible. Then, other resize events with valid values are handled but the window stay in an invisible state.

Celine wrote

The OpenGL context is not destroyed, in fact, the NewtCanvasSWT handle a resize event with a height value = 0, hence the window is marked as invisible. Then, other resize events with valid values are handled but the window stay in an invisible state.

I thought we had removed this kind of hacky solution :s A similar bug has already been fixed in another canvas. Thank you very much for your investigation.

You're right, validateNative fails in this case.

Edit.: There is still the same kind of test in NewtCanvasAWT :(