[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: RFR: JDK-8294427 - Check boxes and radio buttons have rendering issues on Windows in High DPI en
From:       Phil Race <prr () openjdk ! org>
Date:       2023-04-28 21:48:53
Message-ID: jDKWvs3-SqBPy9sgOebDg5ZSPXnIw2qZ2fb3w274yk4=.ba7ad6e1-1a21-425c-9841-60b33ce00faf () github ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]