Pack and SetVisible unsafe

[BestJewSinceJC]

I was doing a bit of reading, and according to what I read, GUIs can be set up and realized in any thread, but doing more GUI work in a normal thread (non-EDT) after a call to setVisible can be dangerous. The explanation given is as follows:

The example constructs the GUI in the main thread. In general, you can construct (but not show) a GUI in any thread, as long as you don't make any calls that refer to or affect already realized components. The components in the GUI are realized by the pack call. Immediately afterward, the components in the GUI are shown with the setVisible (or show) call. Technically the setVisible call is unsafe, because the components have already been realized by the pack call. However, because the program doesn't already have a visible GUI, it's exceedingly unlikely that a paint request will occur before setVisible returns.

I couldn't find any more information on it. How could a paint request possibly occur though. . it can't occur programmatically (before setVisible returns) unless it's in a different thread, which isn't the case here, and it can't occur by user action since the window isn't visible yet. I guess that's why it says exceedingly unlikely. But anyway, why is it unsafe if a paint request occurs before setVisible returns? I'm very curious

:)

[Ezzaral]

The 'unsafe' part would be a chance that some portion of the components might still be in an inconsistent state that would produce errors or graphical "glitches" if a paint request happened to be processed. Essentially it's still "under construction" and may exhibit inconsistent behavior if accessed by another thread.

[Ezzaral]

>How could a paint request possibly occur though. . it can't occur programmatically (before setVisible returns)
It can if the setVisible call is being processed on a thread other than the EDT. Consider that things like moving your mouse over a component, dragging another window across a component, resizing, etc. all generate repaint requests on the EDT. If you're building your GUI on some other thread, the EDT is perfectly free to pop in with a paint request before it's fully constructed.

[BestJewSinceJC]

Ok. So Events can be fired on the Components as soon as they are realized (which happened due to pack) even if they are not visible on the screen yet?

Also, the reason these glitches or inconsistencies could occur is...what exactly? Because setVisible invokes the paint method, so essentially two threads are trying to paint the same window at once, resulting in glitches?

[Ezzaral]

>so essentially two threads are trying to paint the same window at once, resulting in glitches?
Somewhat, yes. I don't have a concrete answer to the "what exactly?" of why the glitches could occur. It would depend entirely on the various UI toolkit code that renders the components and state inconsistencies they may be vulnerable to under certain multiple thread access conditions. I was just speaking generally to the fact that Swing is a single-threaded model and multiple threads attempting to alter the visible state of the components could produce erratic behavior due to inconsistent memory states since they weren't designed for multi-threaded access.

This pdf may be of interest: http://today.java.net/today/2005/04/19/desktop.pdf

[BestJewSinceJC]

Yeah, I've already read a lot about the Swing threading model and memory consistency and WorkerThreads etc, if that's what that link is all about. But I'll check it out. And thanks for your help.