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

Reply via email to