-
Bug
-
Resolution: Unresolved
-
P4
-
11, 15
-
x86_64
-
windows_10
ADDITIONAL SYSTEM INFORMATION :
Windows 10 Pro build 18363
OpenJDK 15.0.2
A DESCRIPTION OF THE PROBLEM :
When having a multimonitor multi scale setup, the resulting image of createMultiResolutionScreen is unpredictable:
- It can be a smaller crop than expected image
- It can be a bigger crop than expected
- It can be offset
- It can be exactly as expected
All of this depends on the input rectangle's center scale.
If the center of the rectangle is in a screen which scale is set to 100% -> the result is a crop with the exact real bounds as the input.
If the center is in a high dpi screen with 200% scale -> the resulting highRes image will be 200% bigger than the input rectangle, with a bigger crop than expected.
I can provide a much more detailed report in PDF with samples.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Have 2 displays, one with 100% scale the other with 200% scale.
Center point in real resolution should be on the 100% display; while center point with scaled down coordinates (while being at the monitor with 200% scaling, window's bounds are scaled respectively) should be at the display with 200% scaling.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When using real bounds -> get a full multiu-screen capture (exactly like Print Screen works)
ACTUAL -
Image is double it's size, with black bands on the sides (the crop is outside real dimensions).
CUSTOMER SUBMITTED WORKAROUND :
Implementing a predictable Robot screen capture method:
private synchronized BufferedImage
createNativeScreenCapture(Rectangle screenRect) {
BufferedImage highResolutionImage;
DataBufferInt buffer;
WritableRaster raster;
if (screenCapCM == null) {
/*
* Fix for 4285201
* Create a DirectColorModel equivalent to the default RGB ColorModel,
* except with no Alpha component.
*/
screenCapCM = new DirectColorModel(24,
/* red mask */ 0x00FF0000,
/* green mask */ 0x0000FF00,
/* blue mask */ 0x000000FF);
}
int[] bandmasks = new int[3];
bandmasks[0] = screenCapCM.getRedMask();
bandmasks[1] = screenCapCM.getGreenMask();
bandmasks[2] = screenCapCM.getBlueMask();
// need to sync the toolkit prior to grabbing the pixels since in some
// cases rendering to the screen may be delayed
Toolkit.getDefaultToolkit().sync();
int[] pixels;
pixels = peer.getRGBPixels(screenRect);
buffer = new DataBufferInt(pixels, pixels.length);
bandmasks[0] = screenCapCM.getRedMask();
bandmasks[1] = screenCapCM.getGreenMask();
bandmasks[2] = screenCapCM.getBlueMask();
raster = Raster.createPackedRaster(buffer, screenRect.width,
screenRect.height, screenRect.width, bandmasks, null);
SunWritableRaster.makeTrackable(buffer);
highResolutionImage = new BufferedImage(screenCapCM, raster,
false, null);
return highResolutionImage;
}
FREQUENCY : occasionally
Windows 10 Pro build 18363
OpenJDK 15.0.2
A DESCRIPTION OF THE PROBLEM :
When having a multimonitor multi scale setup, the resulting image of createMultiResolutionScreen is unpredictable:
- It can be a smaller crop than expected image
- It can be a bigger crop than expected
- It can be offset
- It can be exactly as expected
All of this depends on the input rectangle's center scale.
If the center of the rectangle is in a screen which scale is set to 100% -> the result is a crop with the exact real bounds as the input.
If the center is in a high dpi screen with 200% scale -> the resulting highRes image will be 200% bigger than the input rectangle, with a bigger crop than expected.
I can provide a much more detailed report in PDF with samples.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Have 2 displays, one with 100% scale the other with 200% scale.
Center point in real resolution should be on the 100% display; while center point with scaled down coordinates (while being at the monitor with 200% scaling, window's bounds are scaled respectively) should be at the display with 200% scaling.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When using real bounds -> get a full multiu-screen capture (exactly like Print Screen works)
ACTUAL -
Image is double it's size, with black bands on the sides (the crop is outside real dimensions).
CUSTOMER SUBMITTED WORKAROUND :
Implementing a predictable Robot screen capture method:
private synchronized BufferedImage
createNativeScreenCapture(Rectangle screenRect) {
BufferedImage highResolutionImage;
DataBufferInt buffer;
WritableRaster raster;
if (screenCapCM == null) {
/*
* Fix for 4285201
* Create a DirectColorModel equivalent to the default RGB ColorModel,
* except with no Alpha component.
*/
screenCapCM = new DirectColorModel(24,
/* red mask */ 0x00FF0000,
/* green mask */ 0x0000FF00,
/* blue mask */ 0x000000FF);
}
int[] bandmasks = new int[3];
bandmasks[0] = screenCapCM.getRedMask();
bandmasks[1] = screenCapCM.getGreenMask();
bandmasks[2] = screenCapCM.getBlueMask();
// need to sync the toolkit prior to grabbing the pixels since in some
// cases rendering to the screen may be delayed
Toolkit.getDefaultToolkit().sync();
int[] pixels;
pixels = peer.getRGBPixels(screenRect);
buffer = new DataBufferInt(pixels, pixels.length);
bandmasks[0] = screenCapCM.getRedMask();
bandmasks[1] = screenCapCM.getGreenMask();
bandmasks[2] = screenCapCM.getBlueMask();
raster = Raster.createPackedRaster(buffer, screenRect.width,
screenRect.height, screenRect.width, bandmasks, null);
SunWritableRaster.makeTrackable(buffer);
highResolutionImage = new BufferedImage(screenCapCM, raster,
false, null);
return highResolutionImage;
}
FREQUENCY : occasionally