On Fri, 5 Aug 2022 20:26:31 GMT, Phil Race <p...@openjdk.org> wrote: >> Is that possible? Toolkit thread is not EDT, therefore native events are >> processed, it's probably enough to update the frame coordinates while EDT is >> blocked and doesn't handle events. > > Can you expand on what you mean ? > What's the problem with native events being processed ? We want that. > And this obviously isn't being called on the toolkit thread. > > This change isn't doing anything to that method that might change threading > reqts or rules of use. > Any problems already existed. What is being changed (apart from adding the > new API) is just to make it more robust.
> The intention is that it can be called either way - on or off. @aivanov-jdk As @prrace mentioned, the main reason for opting - **Thread.sleep** approach instead of **robot.waitForIdle()** was to give the test user the flexibility to call `positionTestWindow` on or off EDT. (since test cases can contain either AWT or Swing components). https://github.com/openjdk/jdk/pull/9525#issuecomment-1199911675 With `waitForIdle()` approach we had to wrap parts of the code within EDT and part of it out of EDT, this was confusing and complex. ------------- PR: https://git.openjdk.org/jdk/pull/9525
