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

[Semyon Sadetsky]

On 4/6/2016 2:19 PM, Mario Torre wrote:
> On Wed, Apr 6, 2016 at 12:50 PM, Semyon Sadetsky
> <semyon.sadetsky at oracle.com> wrote:
>> Hello Mario,
>>
>> Seems X11 call would be the best solution for AWT Robot screenshots under
>> Linux. I'm ready to approve it as a default solution.
>> But it seems to me better to preserve the current GTK dependent code as a
>> kind of alternative solution for platforms where GTK is better supported. Is
>> it reasonable for you?
> Do you have in mind some compile time switch to select the appropriate
> code path, or to invert the existing code path to default to x11?
Not compile time switch but run-time. I would introduce a new system 
property, for example "-Dawt.robot.gtk=true". Just in case if your 
solution will stop to work on some platforms or WMs. GTK may be the 
working alternative there.
>
> Generally, I'm a bit unsure what to do. While I agree X11 is currently
> the best most compatible and widespread solution, my main problem with
> it is that with Wayland on the horizon it will be more complex to
> support. For JDK8 I would not bother too much as I expect it being EOL
> before Wayland becomes really a problem[1][2], but JDK9 may likely see
> a lot of Wayland systems during its lifetime. On the other end,
> keeping the GTK code around means we will likely end up in a situation
> where we may have gtk2 and 3 loaded at the same time, unless the gtk 3
> patches discussed elsewhere are pushed, so any fix on this bug should
> be postponed until we see what's the actual code that goes in
> regarding gtk3 support.
The GTK 3 fix is almost ready. It is under review on the Swing alias: 
http://mail.openjdk.java.net/pipermail/swing-dev/2016-April/005661.html. 
Feel free to comment there.
>
> I would say that the best approach is to abstract this code away so
> there's just one place where we request the screenshot from and let
> the backend decide if it's gtk or x11, this way we have a proper fall
> back that depends on using/not using gtk, and which version of gtk,
> but I'm not sure about the level of refactoring this option imply.
That may take noticeable time and we are approaching the release. That 
would be nice to have your fix in 9.
>
> In the long run, we will need to cleanup also the XPeer and all the
> Xlib code and abstract it away or simply replace with GTK or something
> else that hides the Wayland/X11 details, the screenshots are just the
> tip of the iceberg... So overall, I don't know what's best here :)
I agree. It would be nice to introduce another layer to abstract the 
native toolkit. But it will be really huge refactoring. Don't know how 
realistic this could be.

--Semyon
>
> Cheers,
> Mario
>
> [1] But then, who knows...
> [2] In fact, I've been looking at various bugs reported against
> Wayland that all point to Wayland poor support of X11 application so
> far or general instability.