Re: [albireo-dev] inhibitSizePropagationToAWT

[Bruno Haible <haible@xxxxxxx>]

Gordon Hirsch wrote:
> On Windows, I'm currently seeing no size propagation to AWT. Frequently,
> this has the result seen in the attached screenshots.

The reason is a race condition between the code in SwingControl and the
following piece of code from the end of the SWT_AWT.new_Frame method:

        parent.getDisplay().asyncExec(new Runnable() {
                public void run () {
                        if (parent.isDisposed()) return;
                        final Rectangle clientArea = parent.getClientArea();
                        EventQueue.invokeLater(new Runnable () {
                                public void run () {
                                        frame.setSize (clientArea.width, clientArea.height);
                                        frame.validate ();
                                }
                        });
                }
        });

It calls swingControl.getClientArea() at a moment when this is still 64x64
and pushes this size later to the frame, overwriting the 103x130 bounds that
were set by the SwingControl code.

I have a patch that avoids this behaviour (1. call checkPopulated() earlier
than we do now, 2. override SwingControl.getClientArea() to keep track of
the returned rectangle, so that we can override its values before said
invokeLater is executed).

But now I'm facing another problem: flickering of the contents. (*)
If I set the default size to 64x64, it's the AWT contents that is initially
shown twice, with different layouts.
If I set the default size to 1x1, it's the SWT contents outside the
SwingControl. It does a layout first assuming a size of 1x1, then later another
one with the real size.

(*) I'm using the RelayoutExampleView for testing.

I have a slow Windows machine where the time span of this intermediate
layout can be up to 1 sec. In other words, it's very visible, and disturbing.

What can we do about it??

Bruno