RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI env

[Sergey Bylokhov]

On Thu, 27 Apr 2023 19:25:55 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> Problem:
> 
> Check boxes and radio buttons in Windows Look-and-Feel have rendering issues when window is moved from display with one scale to display with a different scale on a multi-monitor setup:
> 
> - Scrawly ticks in checkboxes;
> - Wrong circle relations in selected radio buttons.
> 
> Root-cause:
> We open theme on AWT Toolkit Window which always has Primary Monitor DPI. 
> Due to this when the app window goes to Secondary Screen with different DPI UI buttons
> appear incorrectly rendered. 
> Following is a list proposed changes to fix this issue.
> 
> 
> Proposed Fix with Summary of changes:
> 
> 1. Open a new Theme Handle per the DPI of the Screen where the App window is.
> --> This makes sure we get the correct size for UI buttons based on the DPI of the screen where the app.
> window is.
> 
> 2. GetPartSize() of icons returns size based on standard size = 96 DPI.
> --> This change makes sure that the default size of UI buttons is 96 since we use this on Java side to layout UI.
> 
> 3. Rect size for icons in native paintBackground() function is fetched from Windows that specific DPI.
> -->This makes sure that the UI buttons aren't stretched because the size calculated on Java side is different from what Windows      returns. Thus UI buttons are scaled correctly once we get their size back from Windows.
>  
> 4. Adjust width and the height of the resolution variant image so that for scaling values of 1.25 , 2.25 , and such we  always  floor, while for 1.5, 1.75, 2.5, 2.75 , and such we always ceil.  	 
> --> This helps make sure that for .25s scaling we get better rendering. 
> This is because when we go from Double to Int for pixel rendering we sometimes need to floor or ceil to get crisp rendering.
> 
> As of now with these changes the rendering is crisp and good for all scaling factors with the exception .25s wherein some small artifact is seen sometimes in rendering of buttons but is still much better compared to what we have now.
> 
> 
> Testing:
> 
> Tested locally on my Windows machine with a 2 monitor setup  125%, 150%, 175%, 225% scaling values and on mach5.
> 
> ___________________________________
>  Monitor 1                |    Monitor 2
> (Primary) 		         |
> 				 |
>         125%		 |    175%
> 	150%		 |    175%
> 	150%		 |    225%
> 	175%		 |    175%
> 	175%	         |    150%
> 	175%	         |    225%
> _____________________ |_____________	
> 
> Also tested on setup with scaling values of  up-to 350%.

src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/XPStyle.java line 685:

> 683:             Graphics2D g2d = (Graphics2D) g;
> 684:             AffineTransform  at = g2d.getTransform();
> 685:             int dpi = (int)(at.getScaleX() * 96);

I think this will not work if the image is not VolatileImage, the scale will be = 1 and as a result, the image could be twice smaller than expected on the HiDPI monitor since rescale operation in another place is deleted. Please double-check.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 90:

> 88: 
> 89:         if(dpiAwareWidgetToTheme.containsKey(dpi))
> 90:         {

It seems some changes use different types of formatting, please unify.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 280:

> 278:         readLock.lock();
> 279:         try {
> 280:             return getPoint(getTheme(widget, defaultDPI), part, state, property);

Why does everything else use defaultDPI, is it possible that some values depend on the DPI?

src/java.desktop/windows/native/libawt/windows/ThemeReader.cpp line 119:

> 117:         DTRACE_PRINTLN("Loaded UxTheme.dll\n");
> 118:         OpenThemeDataFuncForDpi = (PFNOPENTHEMEDATAFORDPI)GetProcAddress(
> 119:                                    hModThemes, "OpenThemeDataForDpi");

Do we plan to backport this change to the old versions of JDK? If yes will we plan to support old WIndows? If yes probably we should fallback to the "OpenThemeData" if "OpenThemeDataForDpi" is not available?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180834159
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180827790
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180831572
PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180829485