On Wed, 14 Sep 2022 18:33:47 GMT, Harshitha Onkar <hon...@openjdk.org> wrote:

> JInternalFrame background color seems to overflow into the border region. 
> This issue is more prominently seen on Windows - Metal LAF (with fractional 
> scaling, as shown below). The primary reason is border scaling issue as 
> observed in  - [JDK-8279614](https://bugs.openjdk.org/browse/JDK-8279614) & 
> [JDK-8282958](https://bugs.openjdk.org/browse/JDK-8282958)
> 
> The fix involves a similar approach as described here 
> https://github.com/openjdk/jdk/pull/7449#issuecomment-1068218648. The test 
> checks the midpoint and corners of borders to check if the internal frame's 
> background color is located out of JInternalFrame.
> 
> ![image](https://user-images.githubusercontent.com/95945681/190233555-a7e00f2c-9003-4c11-84fb-207957838c2f.png)

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 
242:

> 240:     @SuppressWarnings("serial") // Superclass is not serializable across 
> versions
> 241:     public static class InternalFrameBorder extends AbstractBorder 
> implements UIResource {
> 242:         private static int corner = 14;

Before it was final, now it is not and it is static - means you are changing it 
down the line. What will happen if two instances will try to change it in a 
different ways - i.e. if there are more than one window and they are on a 
screens with different scale factors? I do not really get the logic - either 
this value is a local one and being calculated for each instance or it is a 
final and constant for all. And seeing how you update it continuously - will it 
not accumulate this change is paintBorder will be called multiple times?

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

PR: https://git.openjdk.org/jdk/pull/10274

Reply via email to