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.
