On Tue, 17 Dec 2024 03:48:27 GMT, Alexander Zuev <kiz...@openjdk.org> wrote:
>> Currently on macOS when mouseMove is given an offscreen coordinate to move >> the mouse to, mouseMove will physically clamp to the edge of the screen, but >> if you try to grab the mouse location immediately after by using >> MouseInfo.getPointerInfo().getLocation() you will get the value of the >> offscreen point. >> >> Windows and linux do this clamping and coordinate handling for us, but new >> distributions may not necessarily handle clamping the same way, so Robot >> should be checking for clamping rather than delegating it to native. >> >> This fix updates shared code to cache the screen bounds and adds a check to >> not exceed the bounds in mouseMove. The caching is done in the Robot >> constructor, so if the screen bounds changes the constructor must be called >> again to update to the new bounds. > > src/java.desktop/share/classes/java/awt/Robot.java line 225: > >> 223: // peer.mouseMove(x, y); >> 224: peer.mouseMove(Math.min(Math.max(x, screenBounds.x), >> screenBounds.x + screenBounds.width), >> 225: Math.min(Math.max(y, screenBounds.y), screenBounds.y + >> screenBounds.height)); > > But that will limit current robot's functionality on the multi-monitor > setups. Right now i can move mouse using robot from one screen to another, > With your change it seems to be impossible? Robot is already created with a screen .. ie GraphicsDevice .. the bounds are from that .. and it is already used elsewhere in Robot If that can be across physical screens it will still work. If screens are separate then Robot is constrained to that anyway. Can you show a specific case where this is a problem ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22781#discussion_r1889053168
