jdk icon indicating copy to clipboard operation
jdk copied to clipboard

Published 20 hours ago • verified publisher icon openjdk

JDK-8015739: Background of JInternalFrame is located out of JInternalFrame

Open honkar-jdk opened this issue 3 years ago • 14 comments
trafficstars

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

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

Progress

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

Issue

  • JDK-8015739: Background of JInternalFrame is located out of JInternalFrame

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 10274

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

Using diff file

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

honkar-jdk avatar Sep 14 '22 18:09 honkar-jdk

:wave: 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.

bridgekeeper[bot] avatar Sep 14 '22 18:09 bridgekeeper[bot]

@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.

openjdk[bot] avatar Sep 14 '22 18:09 openjdk[bot]

Webrevs

mlbridge[bot] avatar Sep 14 '22 18:09 mlbridge[bot]

@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:

8015739: Background of JInternalFrame is located out of JInternalFrame

Reviewed-by: kizune, aivanov

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 599 new commits pushed to the master branch:

  • b847fb687735ae5dff56d12d221556a5218b5bba: 8296414: [BACKOUT] JDK-8295319: pending_cards_at_gc_start doesn't include cards in thread buffers
  • 5b7e70645b311b7060da20cb7ca813df34834332: 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
  • 82f9819eaccd091c9d3a0b89979ddc13b1ef761c: 8294536: Update troff form of man page for new --spec-base-url option
  • b49bdaeade8445584550dbd5c48ea3c7e9cf1559: 8294816: C2: Math.min/max vectorization miscompilation
  • c206f28629056c62d5c22686cc39b849e4ecef2f: 8283101: serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java failing #VirtualThread-Frozen: number of frames expected: 14, got: 9
  • 97c5a64d5cef6da43691a8396d4013145aa04f66: 8296287: Improve documentation for Types.directSupertypes()
  • f9c7cdaed693934a366145b15dcbb2aa65a9da0a: 8294109: JavaDoc search should search whole index
  • 5622b0956581ed5057f708ee77cb648705ea7e94: 8200337: Generalize see and link tags for user-defined anchors
  • 22347e46f7e66a864ea987fa084c44792cae2e6a: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905
  • 12316829b48c58e4509026543a3f2b50a57a439f: 8296305: Remove unimplemented deoptimized_wrt_marked_nmethods
  • ... and 589 more: https://git.openjdk.org/jdk/compare/8ff2c2639e6843333cf220d4427799e21d366764...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.

As you do not have Committer status in this project an existing Committer must agree to sponsor your change. Possible candidates are the reviewers of this PR (@azuev-java, @alisenchung, @aivanov-jdk) but any other Committer may sponsor as well.

➡️ To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration).

openjdk[bot] avatar Sep 30 '22 18:09 openjdk[bot]

Out of curiosity, can this test use BufferedImage to render JInternalFrame into?

aivanov-jdk avatar Oct 03 '22 21:10 aivanov-jdk

Out of curiosity, can this test use BufferedImage to render JInternalFrame into?

@aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?

honkar-jdk avatar Oct 03 '22 22:10 honkar-jdk

@aivanov-jdk Regarding saving the screen capture -

  • When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.
  • For the screenCapture I wanted to use BufferedImage's getScaledInstance() to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.
BufferedImage bufferedImage= robot.createScreenCapture(jFrameBounds);
Image image= bufferedImage.getScaledInstance((int) (scale * bufferedImage.getWidth(null)),
	(int) (scale * bufferedImage.getHeight(null)), Image.SCALE_DEFAULT);

honkar-jdk avatar Oct 04 '22 18:10 honkar-jdk

Out of curiosity, can this test use BufferedImage to render JInternalFrame into?

@aivanov-jdk Thank you for reviewing. I wanted to clarify whether you meant saving just the JInternalFrame into BufferedImage?

Yes, just JInternalFrame. Yet I was talking about rendering rather than capturing from the screen.

aivanov-jdk avatar Oct 04 '22 18:10 aivanov-jdk

@aivanov-jdk Regarding saving the screen capture -

When JIF bounds are used, a partial image of JInternalFrame (JIF) is saved. Hence I'm using the entire outer JFrame bounds to capture the screenshot.

Could be… It shouldn't. Anyway, I have no problem with capturing the entire JFrame.

For the screenCapture I wanted to use BufferedImage's getScaledInstance() to create the scaled version (code snippet below), but experiencing issues while saving it. Currently I'm scaling the original image and re-drawing it using graphics object.

This is definitely not what we want. It just up-scales or down-scales the current image stored in BufferedImage.

When you run in a HiDPI environment or with uiScale set explicitly to a value greater than 1.0, the number of pixels is higher. Robot.createScreenCapture up-scales the passed in rectangle, captures all the pixels and then down-scales the captured screenshot to the user's space coordinates.

At the same time, createMultiResolutionScreenCapture returns a MultiResolutionImage which contains two variants: (1) the base image with the user specified size, down-scaled from the screen; (2) native resolution image with the device size pixels. The second variant will preserve all the pixels seen on the screen.

aivanov-jdk avatar Oct 04 '22 18:10 aivanov-jdk

It looks good to me, except for the comments I left on the coding style.

Yet there's one thing which I noticed in the rendered border. The top left corner has one pixel which is painted over the title bar. It's present in the original painting code. The top right corner has such a pixel too.

The updated code paints the top left corner with that pixel. Yet in the top right corner, it moved to left. top right corner of the JInternalFrame

@aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes. Below is the screenshot of JIF (at 300% scale) rendered when the paintBorder() code is commented out completely. It seems to match the pixel pattern on the title bar.

image

honkar-jdk avatar Oct 05 '22 00:10 honkar-jdk

@aivanov-jdk The extra pixel seems to be added due to JInternalFrame titlebar and not from the paintBorder() code changes.

Good then. It's not from the border.

aivanov-jdk avatar Oct 05 '22 16:10 aivanov-jdk

@aivanov-jdk In addition to review changes, the following changes were made to the test case:

  • To make the test more robust, corner check has been changed from corner pixel check to checking multiple pixels along the corner diagonals.
  • Added break statements to the loops to avoid appending multiple error messages within a check.
  • Saving a single screenshot per uiScale after all the checks are done.

honkar-jdk avatar Oct 05 '22 21:10 honkar-jdk

Two edge cases issues were identified while testing with different frame sizes and on different platforms-

  • One was due to the inherent issue of robot.getPixelColor() which sometimes returns a different pixel color at the edge of border. This is a test issue and is fixed by adding a offset of 1 pixel to the border and corner checks.

  • The other issue occurs only in specific scenario - when the internal frame size is set to 125, 150, 225, 250...etc on uiScale of 1.25 (on Windows). A thin red line is visible at the bottom of the border. This is might be due to the loopCount value.

honkar-jdk avatar Oct 07 '22 17:10 honkar-jdk

With the current update, on some scales the highlight and shadow lines are not positioned exactly at the middle of the border. This is being investigated currently.

honkar-jdk avatar Oct 07 '22 18:10 honkar-jdk

While testing, following issues were observed -

  • Uneven border thickness (no. of pixels painted differed on 4 sides) thus making it difficult to evenly place the shadow and highlight lines - This was resolved by using an even multiplier (4) for border thickness instead of odd (5) and changing border insets to same number (4).
  • Edges of border being painted over background and titlebar resolved by using even multiplier
  • Shadow and highlight line painted at different offsets at left and bottom of the border even though the start location was same - Adding scaled x, y and respective translate to the scaled width and height as suggested by @aivanov-jdk helped to achieve consistent placement of the lines on all scales.
                w = clipRound(at.getScaleX() * width + xx) - xtranslation;
                h = clipRound(at.getScaleY() * height + yy) - ytranslation;

honkar-jdk avatar Oct 21 '22 22:10 honkar-jdk

@aivanov-jdk Fix has been updated since last approval. Can you please re-review.

honkar-jdk avatar Oct 31 '22 16:10 honkar-jdk

/integrate

honkar-jdk avatar Nov 04 '22 19:11 honkar-jdk

@honkar-jdk Your change (at version 4fa349047cbaa35a1ff06bbee2c6131a6ad1b3f7) is now ready to be sponsored by a Committer.

openjdk[bot] avatar Nov 04 '22 19:11 openjdk[bot]

/sponsor

aivanov-jdk avatar Nov 04 '22 19:11 aivanov-jdk

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

  • b847fb687735ae5dff56d12d221556a5218b5bba: 8296414: [BACKOUT] JDK-8295319: pending_cards_at_gc_start doesn't include cards in thread buffers
  • 5b7e70645b311b7060da20cb7ca813df34834332: 8295753: (fs) UnixPath::toRealPath does not return correct case when links not followed
  • 82f9819eaccd091c9d3a0b89979ddc13b1ef761c: 8294536: Update troff form of man page for new --spec-base-url option
  • b49bdaeade8445584550dbd5c48ea3c7e9cf1559: 8294816: C2: Math.min/max vectorization miscompilation
  • c206f28629056c62d5c22686cc39b849e4ecef2f: 8283101: serviceability/jvmti/thread/GetFrameCount/framecnt01/framecnt01.java failing #VirtualThread-Frozen: number of frames expected: 14, got: 9
  • 97c5a64d5cef6da43691a8396d4013145aa04f66: 8296287: Improve documentation for Types.directSupertypes()
  • f9c7cdaed693934a366145b15dcbb2aa65a9da0a: 8294109: JavaDoc search should search whole index
  • 5622b0956581ed5057f708ee77cb648705ea7e94: 8200337: Generalize see and link tags for user-defined anchors
  • 22347e46f7e66a864ea987fa084c44792cae2e6a: 8277775: Fixup bugids in RemoveDropTargetCrashTest.java - add 4357905
  • 12316829b48c58e4509026543a3f2b50a57a439f: 8296305: Remove unimplemented deoptimized_wrt_marked_nmethods
  • ... and 589 more: https://git.openjdk.org/jdk/compare/8ff2c2639e6843333cf220d4427799e21d366764...master

Your commit was automatically rebased without conflicts.

openjdk[bot] avatar Nov 04 '22 19:11 openjdk[bot]

@aivanov-jdk @honkar-jdk Pushed as commit f857f795a9fc8b116bfc6b039114051061950e28.

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

openjdk[bot] avatar Nov 04 '22 19:11 openjdk[bot]