JDK-6189405 : Robot.createScreenCapture is not consistant across virtual screen setups provided by win32/xinerama
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.4.0,1.4.2,5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,linux_redhat_9.0,windows_xp
  • CPU: generic,x86
  • Submitted: 2004-11-02
  • Updated: 2011-01-19
  • Resolved: 2006-04-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b79Fixed
Related Reports
Relates :  
Description
Robot(GD) specifies that this constructor is actually meant for multi-monitor setup with 2 independent screens and any coordinates passed to createScreenCapture() method would be interpreted as being in the same coordinate system as the specified screen. 

Say I am creating a frame on the secondary monitor whose 'X' value starts at 1152. When I call Robot.createScreenCapture() with the above X coordinate where robot is created for the secondary monitor, it captures a black area on win32 but on linux+xinerama, it captures the contents properly. I feel win32 behavior is correct. It interprets 1152 with respect to sec. monitor assuming sec monitor starts at 0,0. So it captures some location that does not exist. But on Xinerama, Robot did not consider 1152 with respect to mon-2 and considers that as a virtual screen location which deviates from the spec. 

This method must behave consistantly across all virtual screen setups, be it win32 or xinerama. This is reproducible since 1.4

I have attached a sample test. Execute the sample test on win32 as well as linux having virtual screen setups. You would see 2 frames. Click on 'capture'. Check whether the image shown on the other frame is captured properly. Click 'Move Frame'. This would change the GD associated with the frame. Click 'Capture' again. If it shows a black frame on win32 and captures the frame properly on xinerama, the bug is reproduced.
###@###.### 11/2/04 12:51 GMT

Comments
EVALUATION Currently, GraphicsDevice parameter in java.awt.Robot constructor is not used when running in Xinerama mode. That is because robot can distinguish only X screens, but while in Xinerama mode there is only one single X screen (run xdpyinfo to test). Also, there are some other robot+Xinerama bugs, in particular, about moving mouse pointer across the screen bounds. I'm afraid that AWT won't be able to rewrite robot implementation in Mustang using another native API, so I'm committing this bug to Dolphin. ###@###.### 2005-06-27 12:31:23 GMT
27-06-2005