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

[Phil Race]

On Fri, 28 Apr 2023 21:23:58 GMT, Sergey Bylokhov <serb 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/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?

I guess this could (should?) be backported but Windows 10 is the oldest supported OS no matter what the JDK version.
And only the more recent versions of Windows 10 at that ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1180838420