grey omero insight login window (linux)

[axkibe]

My login window to omero insight looks like this:

It does this as well with
/usr/lib/jvm/java-8-oracle/bin/java
and
/usr/lib/jvm/java-6-openjdk-amd64/bin/java
Any suggestions?

[Dominik]

Hi,

that's an error I've never seen before. Could you try again with the latest version of Insight? You won't be able to connect to your server, if it is running 5.0.8, but it would be interesting to see if this problem also persists in later versions. In general I'd suggest an update, as 5.0.8 is a bit outdated.
Some other information would be interesting, too. What linux do you use and what graphical environment?

Regards,
Dominik

[axkibe]

Similar issue with "OMERO.insight-5.2.0-ice35-b12-linux" (I updated the server to 5.2 yesterday)

There seems to be a repaint() missing, whenever some event triggers a change the grey starts to become something useful.

I'm currently trying to investigate into this.

On the one hand, grey windows seem to be a prominent java problem, popular workarounds like "export _JAVA_AWT_WM_NONREPARENTING=1" or export "AWT_TOOLKIT=MToolkit" seem to make no difference, similar turning off antialiasing which is said to have helped some. I also ereased no all traces of oracle java on my machine to be sure to have OpenJDK selected for the whole toolchain.

On the other hand, its said to be a common race condition effect, when GUI stuff is not done in the swing Event Dispatch Thread. Or maybe you are just missing a repaint() somewhere on startup, I'm currently trying to build insight from source.

This is on debian jessie using Gnome 3 shell with nvidia/dkms

[axkibe]

After some testing I found you are indeed creating the Splash screen within the "Initializer" thread, while as far I understood the swing rules everything related to swing must be done from within its EDT thread.

I tried to fix this, now the login splash screen construction indeed happens from within the EDT thread, however this didn't change any results at all. Still grey window until every component becomes visible when it repaints itself due to a keyboard event (eg. tabbing through it) . I also put a lot of repaint() and validate() on a lot of places in org/openmicroscopy/shoola/util/ui/login/ScreenLogin.java, no visible effect.

So I'm really not further in this issue.

Code: Select all

--- openmicroscopy-5.2.0/components/insight/SRC/org/openmicroscopy/shoola/env/ui/UIFactory.java 2015-11-02 11:36:18.000000000 +0100
+++ openmicroscopy-axel/components/insight/SRC/org/openmicroscopy/shoola/env/ui/UIFactory.java  2015-12-11 15:24:36.363361076 +0100
@@ -47,16 +47,33 @@

public class UIFactory
{
-
+       static public SplashScreenProxy ssp;
+
        /**
         * Creates the splash screen that is used at initialization.
         *
      * @param c                        Reference to the singleton {@link Container}.
         * @return              The splash screen.
         */
-       public static SplashScreen makeSplashScreen(Container c)
+       public static SplashScreen makeSplashScreen(final Container c)
        {
-               return new SplashScreenProxy(c);
+               Runnable worker;
+
+               try {
+                       worker =
+                               new Runnable()
+                               {
+                                       @Override
+                                       public void run() {
+                                               ssp = new SplashScreenProxy(c);
+                                       }
+                               };
+
+                       javax.swing.SwingUtilities.invokeAndWait( worker );
+               }
+               catch (Exception e) { e.printStackTrace(); }
+
+               return ssp;
        }


[axkibe]

This works around the issue for me:

Code: Select all

--- openmicroscopy-5.2.0/components/insight/SRC/org/openmicroscopy/shoola/env/ui/SplashScreenManager.java   2015-11-02 11:36:18.000000000 +0100
+++ openmicroscopy-mod/components/insight/SRC/org/openmicroscopy/shoola/env/ui/SplashScreenManager.java   2015-12-13 13:08:26.235858018 +0100
@@ -271,6 +271,8 @@
   {
      //close() has already been called.
      view.setVisible(true);
+      view.removeNotify();
+      view.addNotify();
      view.setStatusVisible(true, false);
      isOpen = true;
      container.getRegistry().bind(LookupNames.LOGIN_SPLASHSCREEN,


I'm still not sure what component is at fault here: java, the gnome window manager or omero.

Removing setUndecorated(true) from ScreenLogin works too. However when leaving it undecorated anything after above setVisisble(); only fixes the issue if it forces swing to rebuild its native window manager notification queue. Any calls just to revalidate(); repaint(); pack(); etc. do not have an effect. Fixing the EDT thread issue has no effect either. Changing the size of view for example after setVisible() also fixes the blank window issue...

[Dominik]

Hi,

thanks for your intensive debugging and the workaround you discovered. It seems to be very Gnome3 specific. We're testing on many different systems, but nobody hit this bug yet. I'm going to setup a Debian Gnome3 environment and follow your hints for further investigation. Thank you very much. And sorry for the late reply. Busy times, we're currently preparing the 5.2.1 release.

Regards,
Dominik

[axkibe]

As I found out, this is not an Omero issue. Sorry for the noise. Following Miniapp missbehaves the same way as Omero. Now to figure out who is to blame...

Code: Select all

package jex;

import java.awt.FlowLayout;
import javax.swing.*;

public class Jex {
   public static void main( final String s[] )
   {
      if( s.length == 0 || ( !s[ 0 ].equals( "true" ) && !s[ 0 ].equals( "false" ) ) )
      {
         System.out.println( "Argument must be true/false for setUndecorated" );
         return;
      }


      javax.swing.SwingUtilities.invokeLater(
         new Runnable()   
         {
            public void run() {
               JFrame frame = new JFrame("JEX");
               frame.setUndecorated( s[ 0 ].equals( "true" ) );
           
               JPanel panel = new JPanel();
               panel.setLayout(new FlowLayout());
           
               JLabel label = new JLabel("This is a label!");
           
               JButton button = new JButton();
               button.setText("Press me");
           
               panel.add(label);
               panel.add(button);
           
               frame.add(panel);
               frame.setSize(300, 300);
               frame.setLocationRelativeTo(null);
               frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
               frame.setVisible(true);
            }
         }
      );
   }
}


[Dominik]

Thanks for the code example, very handy for testing. The bug seems to be only present on Gnome3. But as this is the default desktop for many distributions we should have a workaround for it. Just noticed in your example a call to frame.pack() before making the frame visible also works. I'll investigate this further (might also affect other dialogs, not just the login screen) and add a workaround for 5.2.2.

Regards,
Dominik

PS: Added ticket in bug tracking system: https://trac.openmicroscopy.org/ome/ticket/13122

[axkibe]

I also opened a bug against gnome-shell:

https://bugzilla.gnome.org/show_bug.cgi?id=759492

[Dominik]

Looks like the Gnome guys already fixed it, impressively fast! So probably no workaround needed. Will test that issue again with an updated Gnome.

Regards,
Dominik