Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale #1234

Closed

Conversation

andy-goryachev-oracle
Copy link
Contributor

@andy-goryachev-oracle andy-goryachev-oracle commented Sep 7, 2023

Snapping introduces differences between computed values and snapped values, so we need to use non-zero tolerance when checking for equality. The maximum tolerance is (1 / scale) - one display pixel scaled back to the local coordinates.

The tests have been modified to use the scale-specific tolerance.

Tested with macOS at scale 1.0 and win11 at scales (100%, 125%, 150%, 175%).


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-8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale (Bug - P4)

Reviewers

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 1234

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jfx/pull/1234.diff

Webrev

Link to Webrev Comment

@bridgekeeper
Copy link

bridgekeeper bot commented Sep 7, 2023

👋 Welcome back angorya! 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.

@andy-goryachev-oracle andy-goryachev-oracle marked this pull request as ready for review September 7, 2023 18:40
@openjdk openjdk bot added the rfr Ready for review label Sep 7, 2023
@mlbridge
Copy link

mlbridge bot commented Sep 7, 2023

Webrevs

Copy link
Member

@karthikpandelu karthikpandelu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tested the changes in MacOS and Windows at different scales. Tests execute without error in all the cases.
Added minor comment inline.

Copy link
Member

@karthikpandelu karthikpandelu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Member

@kevinrushforth kevinrushforth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes to the test look fine to me. I did ad a question about the new test utility method, but I'll leave it up to you as to whether and how you want to fix it.

// x and y usually have the same scale, so we'll use x
double scale = win.getRenderScaleX();
// distance between pixels in the local (unscaled) coordinates is (1 / scale)
return 1.0 / scale;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this computation what you want? This will give a smaller tolerance for a screen scale of, say, 2.0 (0.5) than it will for 1.0 (1). Intuitively, this seems backwards. For a screen scale of 1, a tolerance of 1 might be too large, whereas for a screen scale of 3, a tolerance of 0.3333 might be too small. If the goal is to account for the results of snapping, then would a fixed tolerance of 0.5 be better? It's possible I'm missing something.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this tolerance is to account for snapping, but it should be one half of the display pixel instead of the whole pixel (i.e. 0.5 / scale).
With 0.5, these tests fail because we need JDK-8299753 to go first (and pass with the fix).

What we can do is to merge this change and change the tolerance as a part of JDK-8299753.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My earlier comment about it being backwards was wrong. Since you are measuring and comparing user space pixels, those are indeed smaller for larger scale values. Ultimately, 0.5 / scale would be a reasonable tolerance value.

What we can do is to merge this change and change the tolerance as a part of JDK-8299753.

Sounds good to me.

@openjdk
Copy link

openjdk bot commented Sep 20, 2023

@andy-goryachev-oracle 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:

8305709: [testbug] Tree/TableViewResizeColumnToFitContentTest fails with fractional screen scale

Reviewed-by: kpk, kcr

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

  • fa73e0d: 8316135: Create release notes for JavaFX 21
  • 2ae8c27: 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling
  • 5e145cc: 8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet
  • f185974: 8251240: Menus inaccessible on Linux with i3 wm
  • f7b21e5: 8315074: Possible null pointer access in native glass
  • 7c8dd1e: 8315958: Missing range checks in GlassPasteboard
  • 624fe86: 8313651: Add 'final' keyword to public property methods in controls
  • 325be56: 8310666: gradle validateSourceSets task not run when TEST_ONLY=true
  • eb7de72: 8315317: Add test for JDK-8262518
  • ed92171: 8315870: icu fails to compile with Visual Studio 2022 17.6.5

Please see this link for an up-to-date comparison between the source branch of this pull request and the master branch.
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.

@openjdk openjdk bot added the ready Ready to be integrated label Sep 20, 2023
@andy-goryachev-oracle
Copy link
Contributor Author

/integrate

@openjdk
Copy link

openjdk bot commented Sep 21, 2023

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

  • 658c833: 8298500: Create test to initially show stage with various attributes (iconified, maximized, full screen)
  • fa73e0d: 8316135: Create release notes for JavaFX 21
  • 2ae8c27: 8255079: RobotTest::testPixelCaptureAverage fails intermittently on Windows with HiDPI scaling
  • 5e145cc: 8199216: Quadratic layout time with nested nodes and pseudo-class in style sheet
  • f185974: 8251240: Menus inaccessible on Linux with i3 wm
  • f7b21e5: 8315074: Possible null pointer access in native glass
  • 7c8dd1e: 8315958: Missing range checks in GlassPasteboard
  • 624fe86: 8313651: Add 'final' keyword to public property methods in controls
  • 325be56: 8310666: gradle validateSourceSets task not run when TEST_ONLY=true
  • eb7de72: 8315317: Add test for JDK-8262518
  • ... and 1 more: https://git.openjdk.org/jfx/compare/8fcd6e5e55967810ec2acd3dcc9b47bae5c70350...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label Sep 21, 2023
@openjdk openjdk bot closed this Sep 21, 2023
@openjdk openjdk bot removed ready Ready to be integrated rfr Ready for review labels Sep 21, 2023
@openjdk
Copy link

openjdk bot commented Sep 21, 2023

@andy-goryachev-oracle Pushed as commit 9658fc7.

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

@andy-goryachev-oracle andy-goryachev-oracle deleted the 8305709.fit branch September 21, 2023 14:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated
3 participants