EVALUATION
To make this tes work on Linux the panel added to the testFrame
must be non double buffered:
p.setDoubleBuffered(false);
however the bug #6903034 prevent this test from fixing
Note that this test works only if there is no toolbar on the top of the workspace,
to make the test work in this case this line:
BufferedImage capture = robot.createScreenCapture(new Rectangle(100, 100));
should be fixed to capture the rectangle with the backgroundFrame's bounds
|
EVALUATION
The fix for 6794764 removed the calls to the setDoubleBiffered(false) method from the Window.setLayeresOpaque() private method. Ealier the double buffering was turned off for the glass pane, the root pane, and the content pane when a frame went non-opaque. When double buffering was enabled, the painting was performed incorrectly, thus requiring to turn off the functionality. This, however, had mainly been tested on MS Windows platform due to some issues with the XToolkit implementation of non-opaque windows.
Currently the toolkit-related issues are fixed. However, transparent windows on X11 work incorrectly. If one restores the calls to the setDoubleBuffered() method in the setLayeresOpaque() method, then the windows start displaying OK on X11.
It looks like the fix for 6683775 does not fix the double-buffering issue completely.
As to why this is only reproducible on X11: most probably because, contrary to WToolkit, the XToolkit.needUpdateWindow() returns false. This slightly changes the logic in the RepaintManager class (and, maybe, some other classes in Swing), thus making the painting a bit different.
Since AWT does not explicitly depends on the double-buffered property of components, the painting artifacts are most likely caused by the Swing painting code. The bug is reassigned to Swing for further evaluation.
|
Java