| Summary: | Problem with java 8 + gnome + JOGL + dual screen | ||
|---|---|---|---|
| Product: | [JogAmp] Jogl | Reporter: | Jonathan <jonathan.gallon> |
| Component: | awt | Assignee: | Sven Gothel <sgothel> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | major | CC: | gouessej |
| Priority: | --- | ||
| Version: | 2.3.2 | ||
| Hardware: | pc_x86_64 | ||
| OS: | all | ||
| Type: | DEFECT | SCM Refs: | |
| Workaround: | TRUE | ||
| Attachments: |
Simple test program
Simple test program with animator |
||
Please test with the very latest version (2.3.2 RC), mention exactly which version of Java you use (8 isn't accurate enough), which OS, etc... Are you talking about this method? https://github.com/sgothel/jogl/blob/master/src/jogl/classes/com/jogamp/opengl/awt/GLCanvas.java#L337 There is no animator in your simple test, is it intentional? Please look at my example: https://gist.github.com/gouessej/3420e2b6f632efdddf98 Created attachment 724 [details]
Simple test program with animator
Hello, Thank you for your answer. Information : - java : 1.8.0_u40 (same behavior with previous version) - os : debian and redhat - gnome : 2.24.2 and 3.14 We use jogl 2.24 in our project, but I also tried last RC version of JOGL. This is exactly this method ! When I remove it and use the super.getGraphicConfiguration() returned value, it works fine. With the actual code, the window "jumps" in the next screen when we drag it and the focus is lost. So it's very hard to work with a dual screen and some jogl windows. Do you reproduce this bug when using NewtCanvasAWT instead of GLCanvas? Please can you make the same test with GLWindow? I suspect that this bug is caused by a change in AWT. By the way, please test with OpenJDK 1.7 update 80 too so that I can determine if the problem only concerns Java 1.8: https://github.com/alexkasko/openjdk-unofficial-builds#openjdk-7-update-80-build-32 Feel free to use an official build if possible. Can you test with any other window manager (KDE, Unity, XFCE, ...)? The bug is not present when I use NewtCanvasAWT and a GLWindow. I tried OpenJDK 1.7 u80 and I have the same bug. We also tried with KDE but the bug is not present. Just with gnome. Is there any recommendation for the canvas to use with JOGL ? GLCanvas or NewtCanvasAWT ? (In reply to comment #6) > The bug is not present when I use NewtCanvasAWT and a GLWindow. > I tried OpenJDK 1.7 u80 and I have the same bug. > > We also tried with KDE but the bug is not present. Just with gnome. > Thank you. > Is there any recommendation for the canvas to use with JOGL ? GLCanvas or > NewtCanvasAWT ? The AWT GLCanvas is the oldest and the most reliable canvas but when there are some problems of transparency with Swing (for example when using a Swing internal frame), I advise the use of GLJPanel. NewtCanvasAWT is a good compromise, it allows to benefit of the speed of NEWT while keeping the compatibility with AWT. We have much more control on it as it's a bridge, it uses NEWT under the hood. The only drawback is that it can be less reliable than GLCanvas in some cases, some events might not be forwarded to NEWT or AWT but it's mostly a limitation of the past. Use the one that fits the best to your needs. (In reply to comment #6) > The bug is not present when I use NewtCanvasAWT and a GLWindow. > I tried OpenJDK 1.7 u80 and I have the same bug. > > We also tried with KDE but the bug is not present. Just with gnome. > Thank you! Indeed I test myself using KDE. Hence I will jump in and fix for 2.3.2, promoted: <https://jogamp.org/wiki/index.php/SW_Tracking_Report_Objectives_for_the_release_2.3.2> Thank you :-) [1] Debian 8.1.0
[2] Mesa3D 10.3.2
[3a] KDE 4.4
[3b] Gnome 3.14
+++
JRE 1.8.0_60 will be described in a followup comment.
+++
Moving from one monitor to another monitor using JRE 1.7.0_79:
[J1] JRE 1.7.0_79
OpenJDK Runtime Environment (IcedTea 2.5.6) (7u79-2.5.6-1~deb8u1)
OpenJDK 64-Bit Server VM (build 24.79-b02, mixed mode)
Summary:
Operation works, even though inefficiently,
since the whole native peer gets destroyed and
recreated by AWT while moving to other monitor.
Seems AWT of JRE 1.7 has not validated the visual-id
and new graphics config compatibility, as we do within GLCanvas.
Differences between KDE and Gnome:
- Draggin is lost when reaching the other monitor on Gnome,
where it works seamless w/ KDE as expected.
[J1.1.1] GLCanvas.removeNotify() is issued by AWT,
i.e. the the native peer gets disposed
while leaving one monitor just to get
re-created on the other monitor.
[6]: java.awt.Frame.removeNotify(Frame.java:1041)
[7]: java.awt.Component.setGraphicsConfiguration(Component.java:1157)
[8]: java.awt.Window.setGraphicsConfiguration(Window.java:3144)
[9]: java.awt.Component$1.setGraphicsConfiguration(Component.java:883)
[10]: sun.awt.X11.XWindowPeer$1.run(XWindowPeer.java:718)
[J1.1.2] The GLEventListener.dispose(..) gets called,
as well as all other resources get disposed.
[J1.1.3] GLCanvas.getGraphicsConfiguration(..)
is issued during disposing GLEventListener / JAWTWindow.lockSurface()
and detects a compatible AWT GC change:
AWT-EventQueue-0: getGraphicsConfiguration() Info: Changed GC and GD
Created Config (n): Old GC X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x136]
Created Config (n): Old GD :0.0
Created Config (n): Parent GC X11GraphicsConfig[dev=X11GraphicsDevice[screen=1],vis=0x21]
Created Config (n): Parent GD :0.1
Created Config (n): New GC X11GraphicsConfig[dev=X11GraphicsDevice[screen=1],vis=0x136]
Created Config (n): New GD :0.1
Created Config (n): Old CF AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type .awt, connection :0.0, unitID 0, awtDevice X11GraphicsDevice[screen=0], handle 0x0], idx 0],
chosen GLCaps[glx vid 0x136, fbc 0x84: rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 32/0/0, dbl, mono , sw, GLProfile[GL3/GL3.sw], on-scr[.]],
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL3/GL3.sw], on-scr[.]],
X11GraphicsConfig[dev=X11GraphicsDevice[screen=0],vis=0x136],
encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0.0, unitID 0, handle 0x7f954800a8a0, owner true, JAWTToolkitLock[obj 0x4f2fd227, isOwner false, <4c8e270e, 8a62f66>[count 0, qsz 0, owner <NULL>]]], idx 0], visualID 0x136, fbConfigID 0x84,
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL3/GL3.sw], on-scr[.]],
chosen GLCaps[glx vid 0x136, fbc 0x84: rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 32/0/0, dbl, mono , sw, GLProfile[GL3/GL3.sw], on-scr[.]]]]
Created Config (n): New CF AWTGraphicsConfiguration[AWTGraphicsScreen[AWTGraphicsDevice[type .awt, connection :0.1, unitID 0, awtDevice X11GraphicsDevice[screen=1], handle 0x0], idx 1],
chosen GLCaps[glx vid 0x136, fbc 0x84: rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 32/0/0, dbl, mono , sw, GLProfile[GL3/GL3.sw], on-scr[.]],
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL3/GL3.sw], on-scr[.]],
X11GraphicsConfig[dev=X11GraphicsDevice[screen=1],vis=0x136],
encapsulated X11GLXGraphicsConfiguration[X11GraphicsScreen[X11GraphicsDevice[type .x11, connection :0.0, unitID 0, handle 0x7f9548673cb0, owner true, JAWTToolkitLock[obj 0x4f2fd227, isOwner false, <4c8e270e, 8a62f66>[count 0, qsz 0, owner <NULL>]]], idx 0], visualID 0x136, fbConfigID 0x84,
requested GLCaps[rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 16/0/0, dbl, mono , hw, GLProfile[GL3/GL3.sw], on-scr[.]],
chosen GLCaps[glx vid 0x136, fbc 0x84: rgba 8/8/8/0, opaque, accum-rgba 0/0/0/0, dp/st/ms 32/0/0, dbl, mono , sw, GLProfile[GL3/GL3.sw], on-scr[.]]]]
Created Config (n): EQUALS CAPS true
The new AWT Config gets propagated to JAWTWindow.
Proposal: This step can probably suppressed during disposal
while reading a 'within-disposing' flag, if required.
However, this action shall not harm.
[J1.1.4] GLCanvas.addNotify() gets called by AWT
for its re-creation on the other monitor.
.. then the GLEventListener.init(..) is being called again
and operation continues normally.
[J2] JRE 1.8.0_60 (Oracle) Java(TM) SE Runtime Environment (build 1.8.0_60-b27) Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) Same behavior as for [J1] ! +++ Note: I have run this on VirtualBox w/ software MesaGL. The screens are being mapped to multiple screen display connections, see [J1.1.3] in comment 10. I need to test on a physical device maybe. Hint: Is your GLEventListener fully functional (in a mathematical sense)? In detail: Does it properly behave when issuing - init - reshape - display - dispose _multiple_ times? (In reply to Sven Gothel from comment #11) > [J2] JRE 1.8.0_60 (Oracle) > Java(TM) SE Runtime Environment (build 1.8.0_60-b27) > Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode) > > Same behavior as for [J1] ! > > +++ > > Note: I have run this on VirtualBox w/ software MesaGL. > The screens are being mapped to multiple screen display connections, > see [J1.1.3] in comment 10. > > I need to test on a physical device maybe. Tested w/ NV driver (Same Debian 8 system) and KDE - same behavior as already reported. The multiple screen display connections are visible here as well! So .. I can only assume you have an issue w/ your application or your graphics driver? Marking this bug WORKSFORME. If you can prove it works .. pls reopen w/ detailed description. Note: I have tested w/ 'com.jogamp.opengl.test.junit.jogl.demos.es2.awt.TestGearsES2AWT -manual -time 100000' |
Created attachment 723 [details] Simple test program Hello, We have a problem with JOGL (version 2.2.4 or lastest) and Gnome on a dual screen environement using Java 8 (works fine in Java 6). When we drag a window from a screen to the other, the window blinks and moves itself to the other screen. So the focus and the drag are lost. After some test, we had try to remove the override method getGraphicsConfiguration() of the GLCanvas and everything works fine. We can drag the frame from screen to screen.