<AWT Dev> Taking screenshots on x11 composite desktop produce wrong result

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Wed Mar 2 16:24:27 UTC 2016

Hi, Mario.
I assume that it works exactly the same as gtk version? if yes then it 
will be good to change the code in jdk9 as well and remove this dependency?

On 01.03.16 16:23, Mario Torre wrote:
> Hi all,
> I have a fix for the issue detailed in the following bug report:
> https://bugs.openjdk.java.net/browse/JDK-8150954
> The issue is does not affect JDK9 so I guess my primary target for the
> bug is jdk8u-dev and the backports will go into 7 and 6 as needed.
> The fix basically checks the _NET_WM_CM_Sn atom (where n is the screen
> number), since the composite manager *MUST* acquire ownership of this
> selection, if there's a selection we're running a compositor and at
> this point, wecan get the window root where the actual compositing
> takes places and get a screenshot of that.
> JDK9 is not affected since the implementation seems to have moved to
> GTK, I see there's some code referring to the old path, but it's
> unlikely to be used in composited desktop anyway, I didn't stress test
> it though.
> The bug report contains images describing various configurations, and
> a simple test case.
> The proposed fix webrevs can be found here:
> http://cr.openjdk.java.net/~neugens/8150954/
> I tried the fix on RHEL 7.2 locally and over a remote x11 connection
> with and without a composite desktop.
> There are two parts, one pertaining the configure machinery (to
> include the necessary XRender/XComposite stuff) and the other is the
> actual awt Robot fix.
> If accepted, the configure should be regenerated, the patch contains
> this as well, but I'm not sure how to deal with the closed bits, so
> some guidance is welcomed.
> Any comments?
> Cheers,
> Mario

Best regards, Sergey.

More information about the awt-dev mailing list