Hello Semyon,
Thank you for review of this fix. This issue depends on race conditions.
In fact this issue is reproducible sometimes also, when the components
are initially added to the container, thus removal with further addition
of the components is not the only scenario of this bug. In the
regression test "ComponentIsNotDrawnAfterRemoveAddTest.java" of the fix
this scenario is checked by the next line.
"94 checkTestableComponents();"
Thank you,
Anton
On 1/28/2016 7:34 PM, Semyon Sadetsky wrote:
Hi,
In the bug description I read that the issue is only reproducible when
the component is removed and then added again. The suggested root
cause does not explain this. Why the issue is not reproducible for
initially added components?
--Semyon
On 1/26/2016 10:48 PM, Anton Litvinov wrote:
Hello,
Could you please review the following fix for the bug.
Bug: https://bugs.openjdk.java.net/browse/JDK-8139581
Webrev: http://cr.openjdk.java.net/~alitvinov/8139581/jdk9/webrev.00
The bug consists in the fact that sometimes X11 "Expose" events
arriving in Toolkit thread during execution of
"XBaseWindow.init(XCreateWindowParams)" method in another thread are
not handled in the method "XBaseWindow.dispatchToWindow(XEvent)",
because "XBaseWindow.initialising" field equals "NOT_INITIALISED" and
"XBaseWindow.checkInitialised()" returns "false". A result of such
not handled "Expose" events is not drawn AWT component, which is
inserted back to AWT container, and whose
"java.awt.Component.paint(Graphics)" method is not called.
The fix removes "InitialiseState.NOT_INITIALISED" from the code and
this lets the mechanism of waiting for "INITIALISED" state work as
designed in the method "XBaseWindow.checkInitialised".
Thank you,
Anton
