RFR: JDK-8015739: Background of JInternalFrame is located out of JInternalFrame
Alexander Zuev
kizune at openjdk.org
Mon Sep 19 19:44:45 UTC 2022
On Wed, 14 Sep 2022 18:33:47 GMT, Harshitha Onkar <honkar at 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.
>
> 
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
More information about the client-libs-dev
mailing list