Plus de capture en java sous gnome avec un robot

Version imprimable

12/06/2023, 21h12
Flodelarab

Plus de capture en java sous gnome avec un robot

Bonjour :coucou:

Quoi ? Quoi ? Quoi ? Qu'est-ce que j'apprends ? On ne peut plus faire, en java, de capture d'écran avec un simple createScreenCapture() d'un objet java.awt.Robot avec Gnome et Linux ? J'obtiens une belle image monochrome noire. Bizarre puisqu'il a compris la taille de mon écran.

Comment palliez-vous le problème ? :calim2: Ne me dites pas qu'il faut négocier avec l'API DBUS. Ou alors donnez un exemple fonctionnel. :oops:

Merci de votre attention :ccool:

Avec du code et quelques infos supplémentaires quant a la version de Java utilise et celle de l'OS ça aurait été mieux.

Le code suivant fonctionne très bien pour moi sur Windows 10 avec l'OpenJDK 20.0.1 mais produit effectivement un gros rectangle noir sur une VM Ubuntu 22 tournant dans Virtual Box avec LibericaJDK 18.0.2. Le problème persiste après un passage sur OpenJDK 20.0.1.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 package test.capture; import javax.imageio.ImageIO; import java.awt.*; import java.io.File; import java.io.IOException; public final class Main { public static void main(final String... args) { System.out.println(System.getProperty("java.version")); screenCapture(); } public static void screenCapture() { try { final var robot = new Robot(); final var env = GraphicsEnvironment.getLocalGraphicsEnvironment(); final var devices = env.getScreenDevices(); final int numberOfScreens = devices.length; for (int index = 0 ; index < numberOfScreens ; index++) { final var device = devices[index]; final var mode = device.getDisplayMode(); final var bounds = device.getDefaultConfiguration().getBounds(); System.out.println(device.getIDstring()); System.out.printf("Min : (%f, %f) ; Max : (%f, %f)%n", bounds.getMinX(), bounds.getMinY(), bounds.getMaxX(), bounds.getMaxY()); System.out.printf("Width : %d ; Height : %d%n", mode.getWidth(), mode.getHeight()); final var rectangle = new Rectangle((int)bounds.getMinX(), (int)bounds.getMinY(), (int)bounds.getWidth(), (int)bounds.getHeight()); final var screen = robot.createScreenCapture(rectangle); ImageIO.write(screen, "jpg", new File("screenshot-%d.jpg".formatted(index))); } } catch (IOException | AWTException ex) { ex.printStackTrace(); } } }
Le soucis ne semble pas être récent sous Linux car des problèmes similaires sont postés sur StackOverflow depuis quelques années. Il est fait mention, par exemple, que Robot n'est pas compatible avec Wayland.
Il est possible de voir si Wayland est activé en faisant :
Code:

1 2 $ echo $XDG_SESSION_TYPE wayland
Il devrait être normalement possible de le désactiver en faisant :

Code:

$ sudo nano /etc/gdm3/custom.conf

puis en dé-commantant la ligne WaylanlEnable=false dans la section [daemon] :
Code:

1 2 3 [daemon] # Uncomment the line below to force the login screen to use Xorg WaylandEnable=false
Une fois la machine (ou GDM) redémarrée, on obtient :
Code:

1 2 $ echo $XDG_SESSION_TYPE x11
Et le même code Java produit alors une capture d’écran correcte.

C'est bizarre car il me semblait avoir vu passer des messages il y a déjà quelques temps disant que ce soucis avait été corrigé. A moins que ça ne soit pour JavaFX (pas testé les captures avec FX quand Wayland activé).

14/06/2023, 01h16
binarygirl

Il y a un PR en cours: https://github.com/openjdk/jdk/pull/13803
Mais sinon, on peut normalement choisir un autre type de session (càd Xorg et même une autre interface graphique) au login.

Quand même bizarre qu'ils mentionnent ScreenCast vu qu'il faut une autorisation préliminaire de l'utilisateur via une boite de dialogue et donc que ça semble pas bien approprie pour des tests automatises.

J'ai fait un test équivalent en FX, marche OK sous Windows et X11, rectangle noir sous Wayland comme de bien entendu :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
package test.capture;
 
import javafx.application.Application;
import javafx.application.Platform;
import javafx.embed.swing.SwingFXUtils;
import javafx.scene.robot.Robot;
import javafx.stage.Screen;
import javafx.stage.Stage;
 
import javax.imageio.ImageIO;
import java.awt.*;
import java.awt.image.BufferedImage;
import java.io.File;
 
public class Main extends Application {
    public static void main(final String... args) {
        System.out.println(System.getProperty("java.version"));
        System.out.println(System.getProperty("javafx.version"));
        Application.launch(args);
    }
 
    public void start(final Stage stage) throws Exception {
        final var robot = new Robot();
        final var screens = Screen.getScreens();
        final int numberOfScreens = screens.size();
        for (int index = 0; index < numberOfScreens; index++) {
            final var screen = screens.get(index);
            final var fxImage = robot.getScreenCapture(null, screen.getBounds());
            var awtImage = SwingFXUtils.fromFXImage(fxImage, null);
            if (awtImage.getTransparency() == Transparency.TRANSLUCENT) {
                final var awtOpaqueImage = new BufferedImage(awtImage.getWidth(), awtImage.getHeight(), BufferedImage.TYPE_INT_RGB);
                final var g2d = awtOpaqueImage.createGraphics();
                try {
                    g2d.drawImage(awtImage, 0, 0, null);
                } finally {
                    g2d.dispose();
                }
                awtImage = awtOpaqueImage;
            }
            ImageIO.write(awtImage, "jpg", new File("screenshot-%d.jpg".formatted(index)));
        }
        Platform.exit();
    }
}

module-info.java

Code:

1
2
3
4
5
module dvp.fx {
    exports test.capture;
    requires javafx.graphics;
    requires javafx.swing;
}

14/06/2023, 20h55
Flodelarab

Déjà, merci pour votre intérêt et merci Bouve pour tes tests approfondis.

C'est effectivement Wayland qui n'est pas conciliant. Et Wayland est maintenant par défaut. Je ne vais pas désactiver Wayland car X11 n'est même pas installé.

Donner un accès à la session graphique à l'exécutable, comme c'est nécessaire pour d'autres applications, ne résout pas le problème.
(export $(egrep -z DBUS_SESSION_BUS_ADDRESS /proc/$(pgrep -u $LOGNAME gnome-session | head -n 1)/environ) && DISPLAY=:0.0 java monObjet)

Du côté de xdotool et wmctrl, ils ne voient qu'un onglet Firefox. Alors que j'ai de nombreux onglets Firefox, une console et une application fenêtrée indépendante standard. :?

Euh... Comme je ne veux pas être un vieux ronchon psycho-rigide qui ne veut pas changer, je vais d'abord étudier la nouvelle façon "Wayland", avant de revenir à X11.

À suivre, donc.
15/06/2023, 04h04
bouye

https://wiki.archlinux.org/title/Screen_capture#Wayland peut-etre ?
15/06/2023, 12h20
Flodelarab

Oui. Ou "Flameshot", qui est dans les dépôts, contrairement à grim. Il est dit fonctionner sous Wayland.

Mais on s'éloigne de plus en plus de l'idée du robot java qui fait tout. En fait, je n'ai pas de solution pour cliquer. Ma conclusion est que, soit on veut faire un robot java comme avant, et on reste sous l'usine à gaz qu'est X11, soit on utilise Wayland qui ne supporte plus les robots (pour le meilleur et le pire).