JDK-8294680: Refactor scaled border rendering #11571

honkar-jdk · 2022-12-07T21:34:12Z

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 functional parameter to the method.

Following are the usual steps 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.

EtchedBorder - PR#7449 - Test: ScaledEtchedBorderTest.java
LineBorder - PR#10681 - Test: ScaledLineBorderTest & ScaledTextFieldBorderTest.java
JInternalFrame Border - PR#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.

Progress

Change must be properly reviewed (1 review required, with at least 1 Reviewer)
Change must not contain extraneous whitespace
Commit message must refer to an issue

Issue

JDK-8294680: Refactor scaled border rendering

Reviewers

Rajat Mahajan (@rajamah - Author) ⚠️ Review applies to 103ca437
Alisen Chung (@alisenchung - Committer) ⚠️ Review applies to 103ca437
Alexey Ivanov (@aivanov-jdk - Reviewer)
Jayathirth D V (@jayathirthrao - Reviewer) ⚠️ Review applies to ffb3dd17

Contributors

Alexey Ivanov <aivanov@openjdk.org>

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk pull/11571/head:pull/11571
$ git checkout pull/11571

Update a local copy of the PR:
$ git checkout pull/11571
$ git pull https://git.openjdk.org/jdk pull/11571/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 11571

View PR using the GUI difftool:
$ git pr show -t 11571

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/11571.diff

bridgekeeper · 2022-12-07T21:36:24Z

👋 Welcome back honkar! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

openjdk · 2022-12-07T21:39:19Z

@honkar-jdk The following label will be automatically applied to this pull request:

client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

honkar-jdk · 2022-12-07T21:41:44Z

/contributor add @aivanov-jdk

openjdk · 2022-12-07T21:42:02Z

@honkar-jdk
Contributor Alexey Ivanov <aivanov@openjdk.org> successfully added.

mlbridge · 2022-12-07T21:44:29Z

Webrevs

mlbridge · 2022-12-08T03:10:25Z

Mailing list message from Alan Snyder on client-libs-dev:

Is there some reason why this should not be a public API?

Do you believe that only JDK-implemented borders need this functionality?

mlbridge · 2022-12-10T01:54:18Z

Mailing list message from Harshitha Onkar on client-libs-dev:

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-retn at openjdk.org> On Behalf Of Alan Snyder
Sent: Wednesday, December 7, 2022 1:53 PM
To: Harshitha Onkar <honkar at openjdk.org>
Cc: client-libs-dev at 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?

rajamah · 2022-12-10T23:05:22Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+        int height = 0;
+
+        if (resetTransform) {
+            double xx = at.getScaleX() * x + at.getTranslateX();


Can we combine this code block with the above if (resetTransform) at line 173 ? or did you keep it separate for a reason?

@rajamah In-order to paint the border even when g is not a Graphics2D object I have added the resetTransform check here again and additionally to keep the if & else block close-by, which is easier to understand rather than having the blocks separated.

sure, makes sense. Thanks

Still, I think it makes sense to combine this block with the above one.

If resetTransform is true, the transform is reset and variables are set to the values as calculated in this block; otherwise, the variables are initialised with the default values.

rajamah · 2022-12-10T23:08:48Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+            resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0));
+
+            if (resetTransform) {
+                g2d.setTransform(new AffineTransform());


Can we keep the original comment about this:
/* Deactivate the HiDPI scaling transform,
* so we can do paint operations in the device
* pixel coordinate system instead of the logical coordinate system.
*/

Sure. I can add it.

I believe @rajamah meant to put this comment before resetting the transform to explain why it's done.

jdk/src/java.desktop/share/classes/javax/swing/border/LineBorder.java

Lines 165 to 169 in 9911405

/* Deactivate the HiDPI scaling transform,

* so we can do paint operations in the device

* pixel coordinate system instead of the logical coordinate system.

*/

g2d.setTransform(new AffineTransform());

The original comment above for resetTransform variable could also be preserved, it explains why we don't reset the transform when shear and/or rotation are used.

mlbridge · 2022-12-11T01:51:16Z

Mailing list message from Alan Snyder on client-libs-dev:

On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com> wrote:

Do you have a specific use case in mind?

No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.

For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221210/21b34089/attachment.htm>

mlbridge · 2022-12-11T01:51:18Z

Mailing list message from Michael Hall on client-libs-dev:

On Dec 10, 2022, at 10:48 AM, Alan Snyder <javalists at cbfiddle.com> wrote:

On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com <mailto:harshitha.onkar at oracle.com>> wrote:

Do you have a specific use case in mind?

No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.

For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.

As I remember a large part of the OS/X port project related to the Aqua LAF. A large undertaking where they probably made as minimal changes as possible and avoided re-inventing of wheels.
So sort of ironic but not that hard to believe.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221210/773502bf/attachment-0001.htm>

mlbridge · 2022-12-12T18:28:17Z

Mailing list message from Andy Goryachev on client-libs-dev:

I second Alan's sentiment. If a helpful utility method is called multiple times from Swing code, it does make sense to make publicly available - chances are it is also useful to the application or third party component developers.

Copying code from Swing has a legal aspect - it probably makes the third party code GPL-d, which is probably not what the stakeholders want.

-andy

From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of Alan Snyder <javalists at cbfiddle.com>
Date: Saturday, 2022/12/10 at 08:48
To: Harshitha Onkar <harshitha.onkar at oracle.com>
Cc: client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: RFR: JDK-8294680: Refactor scaled border rendering

On Dec 9, 2022, at 10:18 AM, Harshitha Onkar <harshitha.onkar at oracle.com<mailto:harshitha.onkar at oracle.com>> wrote:

Do you have a specific use case in mind?

No, but as a developer of a third party LAF and various custom Swing components I have had to duplicate ?private? Swing code multiple times, so I would like to encourage the view that Swing is an open set of components and LAFs and that the built in components and LAFs should not be considered special or privileged.

For amusement, see the JDK class AquaTabbedPaneCopyFromBasicUI where private Swing code was duplicated by Apple and remains.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20221212/76a3131d/attachment.htm>

src/java.desktop/share/classes/javax/swing/border/LineBorder.java

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

aivanov-jdk · 2023-01-04T18:56:14Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+             * so we can do paint operations in the device
+             * pixel coordinate system instead of the logical coordinate system.
+             */
+            resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0));


@rajamah's code in LineBorder.java used a better condition: if the scale is 1, resetting transform can be safely skipped.

jdk/src/java.desktop/share/classes/javax/swing/border/LineBorder.java

Lines 152 to 156 in 9911405

// if m01 or m10 is non-zero, then there is a rotation or shear

// or if no Scaling enabled,

// skip resetting the transform

boolean resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0)) &&

((at.getScaleX() > 1) || (at.getScaleY() > 1));

aivanov-jdk · 2023-01-04T19:00:46Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+            resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0));
+
+            if (resetTransform) {
+                g2d.setTransform(new AffineTransform());


I believe @rajamah meant to put this comment before resetting the transform to explain why it's done.

jdk/src/java.desktop/share/classes/javax/swing/border/LineBorder.java

Lines 165 to 169 in 9911405

/* Deactivate the HiDPI scaling transform,

* so we can do paint operations in the device

* pixel coordinate system instead of the logical coordinate system.

*/

g2d.setTransform(new AffineTransform());

The original comment above for resetTransform variable could also be preserved, it explains why we don't reset the transform when shear and/or rotation are used.

aivanov-jdk · 2023-01-04T19:06:27Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+                stkWidth = c instanceof JInternalFrame ?
+                        clipRound(scaleFactor) : (int) Math.floor(scaleFactor);
+                g2d.setStroke(new BasicStroke((float) stkWidth));


This is supposed to be a generic helper. If strokeWidth depends on the type of component, it's better to handle it in each component separately.

EtchedBorder uses the stoke, LineBorder doesn't use it; however, it uses the value.

So, my suggestion is to calculate the strokeWidth (can't we spell it out, it's easier to read this way, isn't it?) as Math.floor(scaleFactor). The stroke itself isn't created, nor is set here.

The stroke can still be restored here as a convenience. What do others think?

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

src/java.desktop/share/classes/javax/swing/border/LineBorder.java

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

This reverts commit abed51b.

honkar-jdk · 2023-01-05T18:59:36Z

Since strokeWidth is set differently in each case, it has been moved from common code to individual classes.

honkar-jdk · 2023-01-09T17:18:48Z

@aivanov-jdk Please review the updated changes.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

aivanov-jdk · 2023-01-11T20:40:22Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+        if (resetTransform) {
+            Graphics2D g2d = (Graphics2D) g;
+            g2d.setTransform(at);
+            g2d.setStroke(oldStk);


The stroke should always be restored even if the transform wasn't reset. Or it should be done in the implementation of paintUnscaledBorder.

@aivanov-jdk Earlier strokeWidth was set when resetTransform was true and it was restored on the same condition. Now since the stroke width is moved to individual implementation of paintUnscaledBorder, it make sense to restore it outside of resetTranform.

To avoid missing this step, I have restored it in common code than in individual paintUnscaledBorder implementations.

aivanov-jdk · 2023-01-11T20:45:21Z

src/java.desktop/share/classes/javax/swing/border/LineBorder.java

@@ -24,6 +24,8 @@
 */
 package javax.swing.border;

+import com.sun.java.swing.SwingUtilities3;


Let's be consistent: it should go after java.* and javax.* packages.

Either there should be a blank line before com.* or sun.* imports or there shouldn't be.

src/java.desktop/share/classes/javax/swing/border/LineBorder.java

aivanov-jdk · 2023-01-11T20:49:46Z

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

+    private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
+                                    int w, int h, double scaleFactor) {


Suggested change

private void paintUnscaledBorder(Component c, Graphics g, int x, int y,

int w, int h, double scaleFactor) {

private void paintUnscaledBorder(Component c, Graphics g, int x, int y,

int w, int h, double scaleFactor) {

One more space is missing to align.

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

aivanov-jdk

Looks good to me.

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

src/java.desktop/share/classes/javax/swing/border/EtchedBorder.java

src/java.desktop/share/classes/javax/swing/border/LineBorder.java

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

openjdk · 2023-01-13T19:55:36Z

@honkar-jdk This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8294680: Refactor scaled border rendering

Co-authored-by: Alexey Ivanov <aivanov@openjdk.org>
Reviewed-by: rmahajan, achung, aivanov, jdv

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 154 new commits pushed to the master branch:

b317658: 8300399: EdDSA does not verify when there is no message
d85243f: 8300647: Miscellaneous hashCode improvements in java.base
453dbd1: 8298377: JfrVframeStream causes deadlocks in ZGC
1084fd2: 8299973: Replace NULL with nullptr in share/utilities/
dea58ef: 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems
2e4a3c4: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'
e326b86: 8300042: Improve CPU related JFR events descriptions
11df6eb: 8300540: Serial: Remove obsolete comments in GenMarkSweep
8f7faa6: 8300447: Parallel: Refactor PSPromotionManager::drain_stacks_depth
eba87a0: 8300264: Remove metaprogramming/isPointer.hpp
... and 144 more: https://git.openjdk.org/jdk/compare/43847c43ad2e84999554468f79016dd33528ec14...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

aivanov-jdk · 2023-01-19T17:04:34Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+    /**
+     * Used within border classes to add specific border implementation details.
+     */


Suggested change

/**

* Used within border classes to add specific border implementation details.

*/

/**

* A task which paints an unscaled border after {@code Graphics}

* transforms are removed. It's used with the

* {@link #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter)

* SwingUtilities3.paintBorder} which manages changing the transforms and calculating the

* coordinates and size of the border.

*/

aivanov-jdk · 2023-01-19T17:05:03Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+     */
+    @FunctionalInterface
+    public interface UnscaledBorderPainter {
+        void paintUnscaledBorder(Component c, Graphics g,


Suggested change

void paintUnscaledBorder(Component c, Graphics g,

/**

* Paints the border for the specified component after the

* {@code Graphics} transforms are removed.

*

* 

* The x and y of the painted border are zero.

*

* @param c the component for which this border is being painted

* @param g the paint graphics

* @param w the width of the painted border, in physical pixels

* @param h the height of the painted border, in physical pixels

* @param scaleFactor the scale that was in the {@code Graphics}

*

* @see #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter) SwingUtilities3.paintBorder

* @see javax.swing.border.Border#paintBorder(Component, Graphics, int, int, int, int) Border.paintBorder

*/

void paintUnscaledBorder(Component c, Graphics g,

aivanov-jdk · 2023-01-19T17:05:38Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+    /**
+     * Performs common scaling transformation steps required for rendering
+     * the border correctly at different scales.
+     */


Suggested change

/**

* Performs common scaling transformation steps required for rendering

* the border correctly at different scales.

*/

/**

* Paints the border for a component ensuring its sides have consistent

* thickness at different scales.

* 

* It performs the following steps:

* <ol>

* <li>Reset the scale transform on the {@code Graphics},</li>

* <li>Call {@code painter} to paint the border,</li>

* <li>Restore the transform.</li>

* </ol>

*

* @param c the component for which this border is being painted

* @param g the paint graphics

* @param x the x position of the painted border

* @param y the y position of the painted border

* @param w the width of the painted border

* @param h the height of the painted border

* @param painter the painter object which paints the border after

* the transform on the {@code Graphics} is reset

*/

aivanov-jdk · 2023-01-19T17:10:08Z

src/java.desktop/share/classes/com/sun/java/swing/SwingUtilities3.java

+
+        // Step 1: Reset Transform
+        AffineTransform at = null;
+        Stroke oldStk = null;


Suggested change

Stroke oldStk = null;

Stroke oldStroke = null;

Let's spell the word in full. It's used twice in the method and I see no reason to abbreviate it.

honkar-jdk · 2023-01-19T18:41:23Z

/integrate

openjdk · 2023-01-19T18:44:04Z

Going to push as commit 80ab50b.
Since your change was applied there have been 154 commits pushed to the master branch:

b317658: 8300399: EdDSA does not verify when there is no message
d85243f: 8300647: Miscellaneous hashCode improvements in java.base
453dbd1: 8298377: JfrVframeStream causes deadlocks in ZGC
1084fd2: 8299973: Replace NULL with nullptr in share/utilities/
dea58ef: 8300119: CgroupMetrics.getTotalMemorySize0() can report invalid results on 32 bit systems
2e4a3c4: 8293862: javax/swing/JFileChooser/8046391/bug8046391.java failed with 'Cannot invoke "java.awt.Image.getWidth(java.awt.image.ImageObserver)" because "retVal" is null'
e326b86: 8300042: Improve CPU related JFR events descriptions
11df6eb: 8300540: Serial: Remove obsolete comments in GenMarkSweep
8f7faa6: 8300447: Parallel: Refactor PSPromotionManager::drain_stacks_depth
eba87a0: 8300264: Remove metaprogramming/isPointer.hpp
... and 144 more: https://git.openjdk.org/jdk/compare/43847c43ad2e84999554468f79016dd33528ec14...master

Your commit was automatically rebased without conflicts.

openjdk · 2023-01-19T18:44:20Z

@honkar-jdk Pushed as commit 80ab50b.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

openjdk · 2023-08-08T21:24:57Z

@lawrence-andrew The command contributor can only be used in open pull requests.

honkar-jdk added 5 commits September 28, 2022 16:43

refactoring changes - initial commit

25c2287

merge master

5a4a635

revert MetalBorder changes

5644a79

Merge branch 'master' into RefactorBorder_8294484

711d77e

Refactoring changes

19665a6

openjdk bot added the rfr label Dec 7, 2022

openjdk bot added the client label Dec 7, 2022

rajamah suggested changes Dec 10, 2022

View reviewed changes

review changes

103ca43

rajamah approved these changes Dec 13, 2022

View reviewed changes

Merge branch 'master' into RefactorBorder_8294484

f9230af

alisenchung approved these changes Dec 13, 2022

View reviewed changes

turbanoff reviewed Dec 21, 2022

View reviewed changes

src/java.desktop/share/classes/javax/swing/border/LineBorder.java Outdated Show resolved Hide resolved

turbanoff reviewed Dec 21, 2022

View reviewed changes

src/java.desktop/share/classes/javax/swing/border/LineBorder.java Outdated Show resolved Hide resolved

honkar-jdk added 2 commits December 21, 2022 13:56

Merge branch 'master' into RefactorBorder_8294484

8416191

minor changes

e753cb2

aivanov-jdk mentioned this pull request Jan 3, 2023

8299553: Make ScaledEtchedBorderTest.java comprehensive #11836

Closed

3 tasks

test changes

abed51b

aivanov-jdk suggested changes Jan 4, 2023

View reviewed changes

Revert "test changes"

a817c46

This reverts commit abed51b.

honkar-jdk added 2 commits January 4, 2023 14:37

review changes

5aad627

moved strokeWidth logic to individual classes

98e7b07

aivanov-jdk reviewed Jan 11, 2023

View reviewed changes

honkar-jdk added 2 commits January 11, 2023 13:29

Merge branch 'master' into RefactorBorder_8294484

80105b5

removed unused parameters, old stroke changes

9caca6b

aivanov-jdk approved these changes Jan 13, 2023

View reviewed changes

openjdk bot added the ready label Jan 13, 2023

honkar-jdk added 2 commits January 13, 2023 12:29

formatting changes, docs added

9af37c1

copyright year updated

ffb3dd1

jayathirthrao approved these changes Jan 19, 2023

View reviewed changes

aivanov-jdk reviewed Jan 19, 2023

View reviewed changes

java doc update

7e7a36b

aivanov-jdk approved these changes Jan 19, 2023

View reviewed changes

openjdk bot added the integrated label Jan 19, 2023

openjdk bot closed this Jan 19, 2023

openjdk bot removed ready rfr labels Jan 19, 2023

honkar-jdk mentioned this pull request Mar 20, 2024

8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main #18260

Closed

3 tasks

	/* Deactivate the HiDPI scaling transform,
	* so we can do paint operations in the device
	* pixel coordinate system instead of the logical coordinate system.
	*/
	g2d.setTransform(new AffineTransform());

	// if m01 or m10 is non-zero, then there is a rotation or shear
	// or if no Scaling enabled,
	// skip resetting the transform
	boolean resetTransform = ((at.getShearX() == 0) && (at.getShearY() == 0)) &&
	((at.getScaleX() > 1) \|\| (at.getScaleY() > 1));

		private void paintUnscaledBorder(Component c, Graphics g, int x, int y,
		int w, int h, double scaleFactor) {

-    /**
-     * Used within border classes to add specific border implementation details.
-     */
+    /**
+     * A task which paints an <i>unscaled</i> border after {@code Graphics}
+     * transforms are removed. It's used with the
+     * {@link #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter)
+     * SwingUtilities3.paintBorder} which manages changing the transforms and calculating the
+     * coordinates and size of the border.
+     */

-        void paintUnscaledBorder(Component c, Graphics g,
+        /**
+         * Paints the border for the specified component after the
+         * {@code Graphics} transforms are removed.
+         *
+         * <p>
+         * The <i>x</i> and <i>y</i> of the painted border are zero.
+         *
+         * @param c the component for which this border is being painted
+         * @param g the paint graphics
+         * @param w the width of the painted border, in physical pixels
+         * @param h the height of the painted border, in physical pixels
+         * @param scaleFactor the scale that was in the {@code Graphics}
+         *
+         * @see #paintBorder(Component, Graphics, int, int, int, int, UnscaledBorderPainter) SwingUtilities3.paintBorder
+         * @see javax.swing.border.Border#paintBorder(Component, Graphics, int, int, int, int) Border.paintBorder
+         */
+        void paintUnscaledBorder(Component c, Graphics g,

-    /**
-     * Performs common scaling transformation steps required for rendering
-     * the border correctly at different scales.
-     */
+    /**
+     * Paints the border for a component ensuring its sides have consistent
+     * thickness at different scales.
+     * <p>
+     * It performs the following steps:
+     * <ol>
+     *     <li>Reset the scale transform on the {@code Graphics},</li>
+     *     <li>Call {@code painter} to paint the border,</li>
+     *     <li>Restore the transform.</li>
+     * </ol>
+     *
+     * @param c the component for which this border is being painted
+     * @param g the paint graphics
+     * @param x the x position of the painted border
+     * @param y the y position of the painted border
+     * @param w the width of the painted border
+     * @param h the height of the painted border
+     * @param painter the painter object which paints the border after
+     *                the transform on the {@code Graphics} is reset
+     */

JDK-8294680: Refactor scaled border rendering #11571

JDK-8294680: Refactor scaled border rendering #11571

Conversation

honkar-jdk commented Dec 7, 2022 • edited by openjdk bot Loading

Progress

Issue

Reviewers

Contributors

Reviewing

bridgekeeper bot commented Dec 7, 2022

openjdk bot commented Dec 7, 2022

honkar-jdk commented Dec 7, 2022

openjdk bot commented Dec 7, 2022

mlbridge bot commented Dec 7, 2022 • edited Loading

Webrevs

mlbridge bot commented Dec 8, 2022

mlbridge bot commented Dec 10, 2022

Choose a reason for hiding this comment

honkar-jdk Dec 12, 2022 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aivanov-jdk Jan 4, 2023 • edited Loading

Choose a reason for hiding this comment

mlbridge bot commented Dec 11, 2022

mlbridge bot commented Dec 11, 2022

mlbridge bot commented Dec 12, 2022

Choose a reason for hiding this comment

aivanov-jdk Jan 4, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk commented Jan 5, 2023

honkar-jdk commented Jan 9, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aivanov-jdk left a comment

Choose a reason for hiding this comment

openjdk bot commented Jan 13, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

honkar-jdk commented Jan 19, 2023

openjdk bot commented Jan 19, 2023

openjdk bot commented Jan 19, 2023

openjdk bot commented Aug 8, 2023

honkar-jdk commented Dec 7, 2022 •

edited by openjdk bot

Loading

mlbridge bot commented Dec 7, 2022 •

edited

Loading

honkar-jdk Dec 12, 2022 •

edited

Loading

aivanov-jdk Jan 4, 2023 •

edited

Loading

aivanov-jdk Jan 4, 2023 •

edited

Loading

openjdk bot commented Jan 13, 2023 •

edited

Loading