JDK-8150954 : Taking screenshots on x11 composite desktop produce wrong result
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 7,8,9
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • Submitted: 2016-03-01
  • Updated: 2019-01-14
  • Resolved: 2016-07-11
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u192Fixed 9 b130Fixed
The Robot code that grabs the content of the screen uses the default root window. On composite desktop the root window does not contain the final composited desktop, so screenshots taken using this window will generally have black areas instead of transparent or translucent ones, as is demonstrated on the attached screenshots.

The proposed solution is to determine if the desktop is composited or not, and then get a reference to the correct window id, which is either the root window or the compositor owned one.

This bug is quite likely related to:


I believe that the original fix that was backed out by 7043455 because it was trying to acquire the composite window, which is wrong since the XCompositeGetOverlayWindow would always return a valid window id.

The proposed fix uses an Atom to detect if the window manager is a composite wm:

Hi Viktor, I apologise for the delay, it's been quite busy lately. The patch was discussed on awt-dev mailing list already: http://mail.openjdk.java.net/pipermail/awt-dev/2016-March/010742.html I was asked to add support for a system property to choose between GTK and X11 implementation, is this still the case? I should be able to have a patch ready very quickly, it's right on top in my priority queue now.

Mario, could you submit this fix on review at openjdk mailing list? Thx.

Proposed fix for JDK9: http://cr.openjdk.java.net/~neugens/8150954/webrev.02/

Minimal test case

Proposed patch: http://cr.openjdk.java.net/~neugens/8150954/

Hi Sergey, Sorry, I was sidetracked in the middle of filing this bug report, this bug report is for OpenJDK 8 and 7, I didn't try on 6 yet.

Is the problem can be reproduced on jdk9? Implementation was changed to use gtk.