Question

Hello I am writing a GUI application on Java 1.6 with Swing.

I have a pop up screen that should display a gif animation while my Swing gui is loading and also a little bit after.

My pop up screen is a JDialog. Tthe animation should be displayed on a JLabel that was added to the Jdialog the following way:

ImageIcon myImgIcon = getMyImgIcon();
JLabel imageLbl = new JLabel(myImgIcon);
add(imageLbl, BorderLayout.CENTER); 

Now the thing is that the animation only displays after the gui has been loaded. I believe that while the GUI is loading (which is a heavy operation in my application) the EDT is so busy it can’t run the animation.

See How do I show a animated GIF image using a thread.

Now the thing is it would be wrong for me to make the GUI load on a different thread (not EDT) so I don’t know how to solve the problem.

Does anyone have an idea?

Answer 1

You just have to free EDT thread of some heavy tasks and do them in a separate thread. In that case gif animation will work together with other processes running.

You might also create your application interface in a separate thread (yes yes, not inside the EDT) but only until you display it. Afterwards you have should make all changes inside the EDT, otherwise you might encounter a lot of problems.

You can also load more UI elements in a separate thread later, just make sure that you add them onto displayed frames/containers inside EDT – that is the most important thing.

Here is a small example of “heavy-like” interface loading:

public static void main ( String[] args ) throws InvocationTargetException, InterruptedException
{
    // Main window

    final JFrame frame = new JFrame ();

    final JPanel panel = new JPanel ( new FlowLayout ( FlowLayout.LEFT, 5, 5 ) )
    {
        public Dimension getPreferredSize ()
        {
            Dimension ps = super.getPreferredSize ();
            ps.width = 0;
            return ps;
        }
    };
    frame.add ( new JScrollPane ( panel ) );

    frame.setSize ( 600, 500 );
    frame.setDefaultCloseOperation ( JFrame.EXIT_ON_CLOSE );
    frame.setLocationRelativeTo ( null );

    SwingUtilities.invokeAndWait ( new Runnable ()
    {
        public void run ()
        {
            frame.setVisible ( true );
        }
    } );

    // Load dialog

    final JDialog load = new JDialog ( frame );

    JPanel panel2 = new JPanel ( new BorderLayout () );
    panel2.setBorder ( BorderFactory.createEmptyBorder ( 15, 15, 15, 15 ) );
    load.add ( panel2 );

    final JProgressBar progressBar = new JProgressBar ( 0, 100 );
    panel2.add ( progressBar );

    load.setModal ( false );
    load.pack ();
    load.setLocationRelativeTo ( frame );

    SwingUtilities.invokeAndWait ( new Runnable ()
    {
        public void run ()
        {
            load.setVisible ( true );
        }
    } );

    // Heavy task (takes approx. 10 seconds + some time on buttons creation) 

    for ( int i = 0; i < 100; i++ )
    {
        Thread.sleep ( 100 );

        final JButton button = new JButton ( "Button" + i );
        final int finalI = i;

        // Updating panel and progress in EDT
        SwingUtilities.invokeLater ( new Runnable ()
        {
            public void run ()
            {
                panel.add ( button );
                button.revalidate ();
                progressBar.setValue ( finalI );
            }
        } );
    }
}

As you can see – all the interface update operations are made in EDT, everything else runs inside the other thread.

Also notice that main thread is not EDT thread, so we can do something heavy there right away.

In some cases its not needed to display loaded parts of interface right away, so you can add them alltogether at the end of the “heavy” operation. That will save some loading time and will make the initialization code much more simple.

Brief explanation about EDT and what i said in the answer…

…it was something i found after working three years under Swing L&F and lots of Swing-based applications. I digged a lot of Swing sources and found a lot of interesting things that aren’t widely known.

As you know – the whole idea of single thread for interface updates (its EDT in Swing) is about keeping each separate component visual updates (and its events) in a queue and perform them one by one inside that thread. That is needed mainly to avoid painting problems since every component inside single frame is painted to the single image that is kept in memory. The painting order is strict there so one component won’t overwrite another on the final image. Painting order depends on the components tree that is created by adding some components or containers inside another container (that is a basic thing you do when creating any application interface on Swing).

To summ up – you must keep all visual updates (methods/operations that might cause them) inside the EDT. Anything else might be done outside the EDT – for example you can prepare the application interface outside the EDT (again, unless you add/remove/move component inside an already visible container).

Still there might be some internal problems with that in some very very very rare cases. There was a good discussion of that question a long ago here:
http://www.velocityreviews.com/forums/t707173-why-does-jdk-1-6-recommend-creating-swing-components-on-the-edt.html

To be short: since 6th JDK version Sun stated in docs that even Swing components creation should be done inside EDT to avoid possible problems. They might appear in some specific cases with heavy interfaces creation due to the events which occurs while the components are bing created.

Anyway, i’d say that in some cases you might create your interface outside the EDT to avoid loader/application being stuck. In other cases, when it doesn’t matter if application is stuck for the interface creation time – you should use EDT. And i cannot say anything more specific since everything depends on your case…