Toolkit.sync()

[Anthony Petrov]

There's no way to detect this with 100% certainty. On any platform.

Toolkit.sync() is harmless and probably worth calling after your final 
Window.setVisible(true) call. However, this method doesn't do much.

There's several workarounds though. You may want to Thread.sleep() for a 
while (like a second or two) after calling Window.setVisible(true). Note 
that sleep()'ing should be done on a secondary thread, not EDT!
Another approach is to override Window.paint() and/or update() methods 
and assume that after they've been invoked, your window is on the screen 
already.

Again, neither of these methods ensure this. Personally, I feel that 
sleep() is the most reliable way to go. Note that GUI regression tests 
in JDK do use the sleep() approach, although they also call some 
non-public APIs to help it (I'm talking about the SunToolkit.realSync() 
method). However, even this private API does NOT guarantee anything. 
Note that I don't suggest you to use this private API because it is not 
supported and may be removed at any time. Also, you won't be able to use 
it in applets or web-start applications that are executed in a sandbox.

--
best regards,
Anthony

On 6/26/2014 2:08 AM, AJ Gregory wrote:
> Hello....
>
> I'm looking for a way to make sure window updates have made it on screen.
>
> Does this do anything in the Mac implementation?
> Toolkit.getDefaultToolkit().sync();
>
> If not is there some way (in java or jni code) to make sure any window
> paints have happened on screen and aren't still queued?
>
> Thanks!
> -Aj
>