0

Working on a large scale SWT-based application I just stumbled upon some code using the AWT/Swing bridge which totally confused me and made me think about the implications of using two GUI threads.

public void createContent(final String html) {
    // Bridge to AWT
    frame = SWT_AWT.new_Frame(this);
    rootPane = new JPanel();
    rootPane.setLayout(new GridBagLayout());
    JRootPane rp = new JRootPane();
    rp.getContentPane().add(rootPane);
    rp.validate();
    frame.add(rp);
    frame.validate();

    // Create components in AWT user interface thread (deadlock prevention)
    EventQueue.invokeLater(new Runnable() {
        @Override
        public void run() {
            initializeLookAndFeel();
            initializeToolbar();
            initializeHTMLEditor();
            setHTML(html, false);
        }
    });

    rootPane.repaint();
    rootPane.validate();
}

Without going into detail, as you might have guessed a lot of Swing elements are added to the "bridge frame" inside the initialization methods.

What confuses me in this case is the invocation of the AWT event dispatcher thread (EDT) for creation of the Swing components. I would just have added all GUI elements inside the SWT UI thread. I am not sure why it's preferable to split the GUI creation between both threads.

Probably, someone can elaborate on what happens behind the scenes. Especially on the interaction of both threads using the bridge. Why or when would it make sense to dispatch creation of AWT stuff to the EDT like in the code example?

Johnson
  • 306
  • 1
  • 15

1 Answers1

0

In SWT every UI element has to be created/handled/accessed within a UI thread since there is a checkWidget method call before sending system signals. This method checks whether the current thread is a UI thread or not and throws an error. The reason behind this choice is that the graphical context access is single threaded and this applies for swing too. Thus you have to call every widget handling within its proper thread the SWT ones with either Display.syncExec(....) or Display.asyncExec(....) and SWING ones in the EventQueue thread

unique_ptr
  • 586
  • 1
  • 8
  • 22
  • You got a good point here: creating SWT elements within the AWT EventQueue will most likely fail due to the `checkWidget` method. However, the other way round - creating the AWT components within the SWT UI thread - works since there seems to be no such "sanity check" in AWT. In the end, isn't it all just about preventing long running tasks from interfering with GUI responsiveness? So shouldn't it be indifferent where a UI task is executed as long as it is done within one of the UI threads? In fact, using both UI threads there is no guarantee anymore in which order the tasks are processed. – Johnson Jul 21 '15 at 07:52
  • 1
    @Johnson `So shouldn't it be indifferent where a UI task is executed as long as it is done within one of the UI threads?` In theory yes but since Swing "draws" its own components and SWT "calls" system components this would be difficult to put in place. – unique_ptr Jul 30 '15 at 08:55
  • 1
    `In fact, using both UI threads there is no guarantee anymore in which order the tasks are processed.` totally agree thus we should be careful with this and use thread synchronization as much as possible, and one example of this issue is the event dispatch. – unique_ptr Jul 30 '15 at 08:55
  • 1
    `In the end, isn't it all just about preventing long running tasks from interfering with GUI responsiveness?` this is a key point here but not only I think that the way each technology handles the graphical context is also a motivation – unique_ptr Jul 30 '15 at 08:57
  • I am not really convinced that the differences in methodology - the "how the drawing is done" - require both threads to be used. However, your comments point in directions which have to be considered, thx. – Johnson Aug 12 '15 at 15:20