java.lang.StackOverflowError vermeiden?

Ich habe gerade einmal deinen Code von weiter oben getestet.
Die im Fenster angezeigten Werte stimmen

  1. überein und
  2. gehen bei mir aber nur von (0,0) (cursor links oben im eck) bis (1535,863)(cursor rechts unten im eck des bildschirms)

Ich habe den Code in meinem „aktuellen“ Eclipse getestet.

Ich kann später den selben Code auch mal noch in der „alten“ Eclipse Umgebung (java 8, etc.) testen.

Edit:
Ich habs in der alten Eclipse+Java Version gerade getestet:
Da sind die 2 Koordinaten auch gleich, gehen allerdings bis (1919,1079).
Heißt in der alten Version gibt er mir Koordinaten gemäß der Auflösung aus, in der neuen Eclipse+Java Kombi kriege ich die Werte mit dem Faktor 1/1.25 multipliziert.

Danke fürs testen. Dann stammten die ermittelten Werte noch vom Java 8 nehme ich an. Dann könntest Du vermutlich die Werte neu ermitteln und dann die ganzen Kalkulationen sein lassen.

Ist diese Sichtweise korrekt oder habe ich etwas übersehen?

1 „Gefällt mir“

Ist jetzt shcon wieder ne Weile her aber irgendwo hatte ich beim Googeln heute auch was gelesen, mehrere Bug Report wo java 8 und der Robot nicht so zusammenpassten bzgl. Koordinaten.
Also generell schien unter java 8 das mit den koordinaten ziemlich zu spinnen.
Und die Uni nutzt natürlich genau java 8, „weil wir einige Funktionen nutzen die es in späteren java Versionen nicht mehr gibt“. Fragt sich nur Welche -.-

Öh, habs mal gerade getestet im neuen Eclipse.
Ich habe ja diese Klasse, die ich immer laufen lasse wenn ich von was die Position und die rgb Werte brauche:

import java.awt.Color;
import java.awt.MouseInfo;
import java.awt.Point;
import java.awt.Robot;

public class FarbeUnterCursor {

    public static void main(String[] args) throws Exception {
        //System.setProperty("sun.java2d.uiScale", "1");
        Point b;
        int x;
        int y;

        Robot bot = new Robot();
        bot.delay(1000);

        while (true) {

            b = MouseInfo.getPointerInfo().getLocation();
            x = (int) b.getX();
            y = (int) b.getY();
            Color color = bot.getPixelColor(x, y);
            System.out.println("x=" + x + "; y=" + y + "; green=" + color.getGreen() + "; blue=" + color.getBlue()
                    + "; red=" + color.getRed());
            bot.delay(200);
        }
    }

}

(Die erste Kommentar in der Main methode ist neu und hatte ich nie dabei).
Wenn ich, wie bisher die Methode ganz normal laufen lasse, gehen die Koordinaten tatsächlich bis 1535, 863, wie du shcon vermutest.
Falls ich den Kommentarbefehl mit drin habe, gehen die Koordinaten bis 1919,1079, also ohne Skalierung mit drin.

Jedenfalls, wie du vermutest, ohne Rumfingern an den Systemproperties scheinen die Koordinaten nun allso schon diesen 1/Skalierung Faktor mit drin zu haben und umrechnen ist unnötig :slight_smile:
Müsste ich die 4-5 Punkte nur nochmal nachmessen, dann kann man die Rechnerei weglassen.
Wäre ja auch recht nice dann :slight_smile:

1 „Gefällt mir“

Dies ganzen Skalierungsfragen waren doch schon in Java Bildschirmkoordinaten vs Bilder Dimensionen - #4 von Marco13 ein Ärgernis. Anscheinend ist es schwierig, da definitive Antworten zu bekommen…

1 „Gefällt mir“

Definitiv, ich verstehe nicht waurm Java da nicht einfach die nackten kalten, auf die normale Auflösung bezogenen Koordinaten benutzt und angibt.
Statt in der einen Klasse und Methode irgendwelche skalierten Koordinaten zu erwarten und anderswo wieder ohne Skalierung zu arbeiten…

Naja, nun kriege ich wenigstens überall (Alles was die Robot Klasse angeht) nur skalierte Koordinaten, damit lässt sich dann wiederum arbeiten :slight_smile:

Das wäre aus meiner Sicht falsch. Die physikalischen Koordinaten gehen eine Applikation (normalerweise) nichts an. Das Betriebssystem ist verantwortlich für die Skalierung. Dazu hat es den physikalischen Bildschirm auf einen virtuellen Bildschirm zu transformieren. Das ist ähnlich wie ein Umschalten der Auflösung - wo dann ggf. der Monitor das skalieren würde auf eine physische Größe.

Muss ich jetzt nicht zwingend verstehen, ich sehe nur „meine Auflösung ist 1920 x 10980“, dann erartet man eigentlich darauf bezogene Pixelangaben. Zumindest ich tue das :slight_smile:

Habe jetzt auch nicht wirklich den plan was jetzt der Computer intern noch mit dpi, inches und Co. umrechnet.

Mal eine andere Idee, wie wäre es nicht Pixelkoordinaten, sondern die relative Positionen zu nehmen? Auf der GPU z.B. werden Bildschirmkoordinaten immer zwischen 0 und 1 angegeben, wobei der Punkt (0.5|0.5) dann die Mitte des Bildschirms wäre, also 50% Höhe, 50% Breite. Könnte man doch hier auch machen, oder nicht?

So eine Normalisierung ist oft gut und richtig und sinnvoll. Der Punkt ist halt, dass man irgendwann den Robot oder PointerInfo verwenden will, und das alles nur auf Pixelkoordinaten arbeitet, und man genau wissen muss, was man dort wie umrechnen muss, um diese ~„virtuelle Skalierung“ richtig einzubeziehen. Im verlinkten Thread hatte ich da mal kurz geschaut (aber habe nicht mit eigenen Skalierungen rumprobiert - das würde mir hier zu viel raushauen…), aber es ist schon eine Weile her, und irgendwann kamen keine Antworten mehr. Ganz grob könnte ein Problem halt (im Pseudocode) sein:

// Maus ist ganz unten rechts auf einem 1600x1200-Screen:
Point mousePosition = PointerInfo.getLocation();
System.out.println(mousePosition); // Gibt 1600,1200 aus

// Versuche die Maus um 10 pixel nach oben links zu bewegen:
robot.moveTo(mousePosition.x-10, mousePosition.y-10);

Und es könnte sein, dass die Maus jetzt bei falschen Koordinaten landet, weil im einen Fall in den Koordinaten eine 125%-Skalierung drinsteckt (oder angenommen wird) und im anderen nicht. Da müßte man mehr lesen und/oder ausprobieren (manchmal scheint das nicht explizit dokumentiert zu sein - aber vielleicht kann man eine allgemeine Regel ableiten…)

1 „Gefällt mir“

Hilft eigentlich nur, dass es die Lib-Entwickler von Java selber machen ^^ Das ist ja grausig.