Bug 1198 - Problem with java 8 + gnome + JOGL + dual screen
Summary: Problem with java 8 + gnome + JOGL + dual screen
Status: RESOLVED WORKSFORME
Alias: None
Product: Jogl
Classification: JogAmp
Component: awt (show other bugs)
Version: 2.3.2
Hardware: pc_x86_64 all
: --- major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2015-08-24 16:56 CEST by Jonathan
Modified: 2015-10-06 18:45 CEST (History)
1 user (show)

See Also:
Type: DEFECT
SCM Refs:
Workaround: TRUE


Attachments
Simple test program (1.40 KB, application/octet-stream)
2015-08-24 16:56 CEST, Jonathan
Details
Simple test program with animator (2.79 KB, application/octet-stream)
2015-08-26 10:05 CEST, Jonathan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan 2015-08-24 16:56:41 CEST
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.
Comment 1 Julien Gouesse 2015-08-25 17:52:56 CEST
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...
Comment 2 Julien Gouesse 2015-08-25 17:57:49 CEST
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
Comment 3 Jonathan 2015-08-26 10:05:29 CEST
Created attachment 724 [details]
Simple test program with animator
Comment 4 Jonathan 2015-08-26 11:03:34 CEST
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.
Comment 5 Julien Gouesse 2015-08-26 12:00:17 CEST
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, ...)?
Comment 6 Jonathan 2015-08-27 14:33:32 CEST
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 ?
Comment 7 Julien Gouesse 2015-08-27 17:11:51 CEST
(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.
Comment 8 Sven Gothel 2015-08-27 20:53:42 CEST
(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>
Comment 9 Jonathan 2015-08-28 08:31:01 CEST
Thank you :-)
Comment 10 Sven Gothel 2015-09-29 04:48:54 CEST
[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.
Comment 11 Sven Gothel 2015-09-29 05:03:46 CEST
[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?
Comment 12 Sven Gothel 2015-09-29 05:21:59 CEST
(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'