-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8160755: bug6492108.java test fails with exception Image comparison failed at (0, 0) for image 4 in GTK L&F #19381
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
Conversation
👋 Welcome back abhiscxk! A progress list of the required criteria for merging this PR into |
@kumarabhi006 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:
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 924 new commits pushed to the
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 |
@kumarabhi006 The following label will be automatically applied to this pull request:
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. |
Webrevs
|
addTextComp(parent, text); | ||
|
||
text = type.newInstance(); | ||
if (showText) text.setText(name + "\ndisabled"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
showText
is never initialized, meaning this condition is never executed. Can be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
} | ||
} | ||
|
||
public void onBackgroundThread30() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unused, can be removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually it is not unused and is run on the background thread to allow enough time for visual verification
. I will check once in the CI testing after removing this method and if there is no failure, it can be removed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I verified with debug, its not used in background thread too. Please do verify once and remove if not used......
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually I can see the debug output in my local run.
invoking: onEDT10 onEDT10 invoking: onBackgroundThread20 onBackgroundThread20 invoking: onBackgroundThread30 onBackgroundThread30
But as I told before this may not impact the result of the test, it is just to add extra delay to provide visual verification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, true..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested in CI and there is no failure for multiple run. Removed this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But as I told before this may not impact the result of the test, it is just to add extra delay to provide visual verification.
In this case, it can be removed.
We want tests to run fast, don't we?
When debugging, it makes sense to increase the delays so that you can see what's going on on the screen.
Tested in CI and there is no failure for multiple run. Removed this method.
Thanks! I noticed it after I had written the comment.
* @summary Verifies that the background is painted the same for | ||
* JTextArea, JTextPane, and JEditorPane. | ||
* @library /javax/swing/regtesthelpers | ||
* @build SwingTestHelper |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this test be marked only for linux?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since test was written originally to run in GTK L&F, updated the test to run only on linux machine.
UIManager.setLookAndFeel( | ||
"com.sun.java.swing.plaf.gtk.GTKLookAndFeel"); | ||
} catch (Exception e) { | ||
System.out.println("GTK LAF is not supported on this system; test passes"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this be jtreg.testSkipped exception?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
return panel; | ||
} | ||
|
||
private void onEDT10() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this method required? can it be rewritten to not use onEDT10 and onBackgroundThread20?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be re-written without using onEDT10
and onBackgroundThread20
.. but I kept it as it was in original test. Don't see any strong reason to change also and there are many other tests which used SwingTestHelper
utility to perform the testing.
private static void addTextComps(Container parent, | ||
Class<? extends JTextComponent> type) | ||
throws Throwable | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think formatting here looks a little odd, could probably move the bracket onto the same line as throws Throwable
and shift it over to the right to match Class<? extends JTextComponent> type)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previous formatting was less confusing and aligned with Java Coding Style Guidelines.
The parameters to the method are aligned to the opening parenthesis; the throws
clause is not part of the parameters and it's placed on another line according to rules of wrapping lines (it should've used double-indentation of 8 spaces rather than 4 spaces to indicate a continuation line).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverted back to previous formatting with double-indentation. Hopefully this should be ok now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This formatting looks good to me.
|
||
if (refimg.getWidth() != testimg.getWidth() || | ||
refimg.getHeight() != testimg.getHeight()) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move bracket to previous line to be consistent
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Initially I thought of doing so but in one of the PR it was mentioned that "We generally prefer the { on a new line if the conditional is multi-line" #18703 (comment).
So I left like that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't say that “We generally prefer the { on a new line if the conditional is multi-line” really holds, yet I agree it makes code less confusing by separating the condition and its continuation lines from the inside block.
To make the continuation line stand out as continuation line, place the ||
at the start of wrapped line.
Again, there's no agreed upon set of style guidelines.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make the continuation line stand out as continuation line, place the || at the start of wrapped line.
Updated.
@aivanov-jdk @alisenchung All review comments are addressed. Please review. |
throw new SkippedException("GTK LAF is not supported on this system;" + | ||
" test passes"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
throw new SkippedException("GTK LAF is not supported on this system;" + | |
" test passes"); | |
throw new SkippedException("GTK LAF is not supported on this system"); |
I'd remove the additional message. I believe it was println
before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
private static void addTextComps(Container parent, | ||
Class<? extends JTextComponent> type) | ||
throws Throwable | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This formatting looks good to me.
Rectangle refRect = | ||
new Rectangle(loc.x, loc.y, ref.getWidth(), ref.getHeight()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rectangle refRect = | |
new Rectangle(loc.x, loc.y, ref.getWidth(), ref.getHeight()); | |
Rectangle refRect = new Rectangle(loc, ref.getSize()); |
requestAndWaitForFocus(panel); | ||
} | ||
|
||
private void onBackgroundThread20() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This method should run on EDT because it accesses the state of the components.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to run this on EDT.
if (refimg.getWidth() != testimg.getWidth() | ||
|| refimg.getHeight() != testimg.getHeight()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if (refimg.getWidth() != testimg.getWidth() | |
|| refimg.getHeight() != testimg.getHeight()) | |
if (refimg.getWidth() != testimg.getWidth() | |
|| refimg.getHeight() != testimg.getHeight()) |
One more space, it should be aligned to the inside of the parenthesis.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Used Util to compare images, so these lines are removed now.
loc = test.getLocationOnScreen(); | ||
Rectangle testRect = | ||
new Rectangle(loc.x, loc.y, | ||
test.getWidth(), test.getHeight()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
loc = test.getLocationOnScreen(); | |
Rectangle testRect = | |
new Rectangle(loc.x, loc.y, | |
test.getWidth(), test.getHeight()); | |
loc = test.getLocationOnScreen(); | |
Rectangle testRect = new Rectangle(test.getLocationOnScreen(), | |
test.getSize()); |
Choose one style and adjust both statements, refRect
and testRect
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to use same style for both places.
test.getWidth(), test.getHeight()); | ||
BufferedImage testimg = robot.createScreenCapture(testRect); | ||
|
||
if (refimg.getWidth() != testimg.getWidth() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest moving the part that compares the images into a helper method. Alternatively, you can use Util.compareBufferedImages
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok.. Updated Util.compareBufferedImages to compare images.
fail("Image comparison failed at (" + | ||
x + "," + y + ") for image " + index); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding count
and k
to diagnostic message could help identifying the failing case quicker.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't find adding k
to diagnostic message useful.. failure message is more relevant now about the images which are compared.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The images themselves are more useful for sure. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You should update the copyright year.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see it in the PR. Didn't push?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh my bad, I missed to add that changes. Pushed now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ran bug6492108.java with changes. LGTM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
/integrate |
Going to push as commit 5dcb7a6.
Your commit was automatically rebased without conflicts. |
@kumarabhi006 Pushed as commit 5dcb7a6. 💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored. |
bug6492108.java test always fails in GTK L&F in single as well as dual screen linux machines. Since this test was not marked as "headful" in it's initial version, it never failed but after the fix of JDK-8287051 this test was problem listed as it always
failed which is captured in the JBS.
The reason of failure is the pixel color mismatch between JEditorPane and JTextArea/JTextPane which is caused by the JEditorPane's default opaque value which is false for GTK3 at L767.
In initial load JEditorPane, JTextArea and JTextPane components are opaque at L718 but after the fix for JDK-8145547 the implementation was changed to provide conditional support for GTK3 on linux where few components like Editor Pane, Formatted text Field, Password Field etc are opaque only if the GTK version is not 3.
JTextPane's issue was observed by JDK-8218479 and then the default opacity is set to true for JTextPane irrespective of GTK version.
Extending the fix in isOpaque() method in GTKStyle.java for JEditorPane similar to JTextPane resolves the issue.
Test verified in both single and dual screen linux machines.
Progress
Issue
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/19381/head:pull/19381
$ git checkout pull/19381
Update a local copy of the PR:
$ git checkout pull/19381
$ git pull https://git.openjdk.org/jdk.git pull/19381/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 19381
View PR using the GUI difftool:
$ git pr show -t 19381
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/19381.diff
Webrev
Link to Webrev Comment