Hi Alan, Thank you for the questions. Please find the answers below.
> Is there some reason why this should not be a public API? We are still testing out this code. Since each border is different (apart from the common steps required for border scaling issue), the solution must be well-baked, tested thoroughly and extensively before it becomes a part of public API. After more borders in JDK are updated and the refactored solution is considered robust & stable, the question of whether to make this utility method a public API can be discussed again. At this time, it might be too early for it. > Do you believe that only JDK-implemented borders need this functionality? The current solution is in its initial stage and we haven't yet determined what applications may or may not need this functionality. Additionally we haven't updated all the JDK borders yet, so we might encounter changes (if any) that may require iterative update to the current solution. Do you have a specific use case in mind? Thanks & Regards, Harshitha Onkar -----Original Message----- From: client-libs-dev <client-libs-dev-r...@openjdk.org> On Behalf Of Alan Snyder Sent: Wednesday, December 7, 2022 1:53 PM To: Harshitha Onkar <hon...@openjdk.org> Cc: client-libs-dev@openjdk.org Subject: Re: RFR: JDK-8294680: Refactor scaled border rendering Is there some reason why this should not be a public API? Do you believe that only JDK-implemented borders need this functionality? > On Dec 7, 2022, at 1:44 PM, Harshitha Onkar <hon...@openjdk.org> wrote: > > In this fix, the common code required for scaled border rendering is unified > and added to SwingUtilities3. This is achieved by adding a functional > interface to SwingUtilities3 and calling the the respective paintBorder > function passed as parameter to method. > > The following steps are common for any border scaling - > > - Resetting transform. > - Calculating new width, height, x & y-translations. > - Perform the required border rendering. > - And at the end restore the previous transform. > > To test the refactored code, 3 separate border scaling instances were taken > (details below) and the SwingUtilities3.paintBorder, (containing the common > functionality) was applied. All the tests associated with the respective > border changes pass. > > 1. EtchedBorder - [PR#7449](https://github.com/openjdk/jdk/pull/7449) > - Test: ScaledEtchedBorderTest.java 2. LineBorder - > [PR#10681](https://github.com/openjdk/jdk/pull/10681) - Test: > ScaledLineBorderTest & ScaledTextFieldBorderTest.java 3. > JInternalFrame Border - > [PR#10274](https://github.com/openjdk/jdk/pull/10274) - Test: > InternalFrameBorderTest.java > > The advantage of this solution is - it avoids code repetition and can be > reused across all the border classes requiring border scaling fix. > > ------------- > > Commit messages: > - Refactoring changes > - Merge branch 'master' into RefactorBorder_8294484 > - revert MetalBorder changes > - merge master > - refactoring changes - initial commit > > Changes: https://git.openjdk.org/jdk/pull/11571/files > Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11571&range=00 > Issue: https://bugs.openjdk.org/browse/JDK-8294680 > Stats: 272 lines in 4 files changed: 94 ins; 146 del; 32 mod > Patch: https://git.openjdk.org/jdk/pull/11571.diff > Fetch: git fetch https://git.openjdk.org/jdk > pull/11571/head:pull/11571 > > PR: https://git.openjdk.org/jdk/pull/11571 >
