-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
16
ADDITIONAL SYSTEM INFORMATION :
Windows 10/ JDK 16.0.1
A DESCRIPTION OF THE PROBLEM :
When obtained from a scaled secondary HDPI screen, GraphicsConfiguration.getBounds() does not return the same value in JDK 16 as it does in prior JDK versions. In JDK 16 the x y coordinates of the bound rectangle are in device space (unscaled) whereas in prior versions they are in scaled space. The width and height are in scaled space in both JDK 16 and earlier. This causes problems for applications wishing to view the coordinate system as a continuous space corresponding to screen layout, or map desktop coordinates to unscaled device coordinates, and also has implications for code relying on the absolute desktop location of awt windows.
REGRESSION : Last worked in version 15
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Arrange a HDPI display scaled to 150% as a secondary display with OS display layout positioned centrally above a primary display. e.g Typical laptop/ second screen configuration (for example same screen config as bug JDK-8261725). Use the test code below and change only the JDK to see the change.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
java.version=15 (also 14.0.1, 11.01)
gc.getBounds=java.awt.Rectangle[x=-720,y=-1440,width=2560,height=1440]
ACTUAL -
java.version=16.0.1
gc.getBounds=java.awt.Rectangle[x=-1080,y=-2160,width=2560,height=1440]
---------- BEGIN SOURCE ----------
public static void main(String [] args) {
System.out.printf("System.getProperty(\"java.version\")=%s\n",System.getProperty("java.version"));
GraphicsEnvironment genv = GraphicsEnvironment.getLocalGraphicsEnvironment();
for (GraphicsDevice gd:genv.getScreenDevices()) {
GraphicsConfiguration gc = gd.getDefaultConfiguration();
System.out.printf("gd.getIDstring=%s, gc.getDefaultTranform=%s, gc.getBounds=%s\n",gd.getIDstring(),gc.getDefaultTransform(),gc.getBounds());
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I do not believe there is a JDK version independent way to tell that the gc bounds x.y values are in a non scaled space on jDK 16. So code must consider which JDK it is running on and perform appropriate adjustment on every getBounds() x,y values call (and awt window location values) to account for the bug,
FREQUENCY : always
Windows 10/ JDK 16.0.1
A DESCRIPTION OF THE PROBLEM :
When obtained from a scaled secondary HDPI screen, GraphicsConfiguration.getBounds() does not return the same value in JDK 16 as it does in prior JDK versions. In JDK 16 the x y coordinates of the bound rectangle are in device space (unscaled) whereas in prior versions they are in scaled space. The width and height are in scaled space in both JDK 16 and earlier. This causes problems for applications wishing to view the coordinate system as a continuous space corresponding to screen layout, or map desktop coordinates to unscaled device coordinates, and also has implications for code relying on the absolute desktop location of awt windows.
REGRESSION : Last worked in version 15
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Arrange a HDPI display scaled to 150% as a secondary display with OS display layout positioned centrally above a primary display. e.g Typical laptop/ second screen configuration (for example same screen config as bug JDK-8261725). Use the test code below and change only the JDK to see the change.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
java.version=15 (also 14.0.1, 11.01)
gc.getBounds=java.awt.Rectangle[x=-720,y=-1440,width=2560,height=1440]
ACTUAL -
java.version=16.0.1
gc.getBounds=java.awt.Rectangle[x=-1080,y=-2160,width=2560,height=1440]
---------- BEGIN SOURCE ----------
public static void main(String [] args) {
System.out.printf("System.getProperty(\"java.version\")=%s\n",System.getProperty("java.version"));
GraphicsEnvironment genv = GraphicsEnvironment.getLocalGraphicsEnvironment();
for (GraphicsDevice gd:genv.getScreenDevices()) {
GraphicsConfiguration gc = gd.getDefaultConfiguration();
System.out.printf("gd.getIDstring=%s, gc.getDefaultTranform=%s, gc.getBounds=%s\n",gd.getIDstring(),gc.getDefaultTransform(),gc.getBounds());
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
I do not believe there is a JDK version independent way to tell that the gc bounds x.y values are in a non scaled space on jDK 16. So code must consider which JDK it is running on and perform appropriate adjustment on every getBounds() x,y values call (and awt window location values) to account for the bug,
FREQUENCY : always