On 18/01/2018 18:36, Krishna Addepalli wrote:
Here is my understanding of waitForIdle() - it ensures that all the events on the EDT are pushed, and it has a huge wait time of 10seconds, which should mostly guarantee that there are no pending events on the EDT till the function is executed. And it mostly works on all platforms. The test case failed on OEL, whereas it passed on Windows and Linux. I haven't checked for Mac, but most likely it would work there too. The testcase in question tries to paint the window, and then picks the color from a particular location on screen. The function bug8024864::showTestUI has frame.setVisible(true) as its last statement, which should ultimately generate a native paint event. Now waitForIdle will ensure that, that event has been posted, but paint/repaint will involve some work down the OS level. Now, it could be possible that, the scheduler might choose to suspend the EDT thread and run the main thread, which checks for the pixel color on the screen and it might fail.
waitForIdle() was implemented in a way that it should block the thread on which it was run until all events will be processed on EDT *and* on native queue. It also takes into account that if at least one event was processed on EDT/native then it should start from the beginning because native events may generate event on EDT, and events on EDT may generate the native events.
So it is unclear why if does not work. -- Best regards, Sergey.
