8187759: Background not refreshed when painting over a transparent JFrame

[TejeshR13]

This is happening in linux where BuffereStrategyPaintManager is used to paint to offscreen. Here bsg bufferStrategy SunGraphics2D is used to paint to offscreen where the background is not refreshed, which does only clipping and then paints to offscreen. In order to handle the screen updated/clear the buffer, setBackground to component background color and clearRect against the clip area is used which solves the issue without causing any regression.
CI is green for the fix and manual test is provided.

---

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-8187759: Background not refreshed when painting over a transparent JFrame (Bug - P3)

Reviewers

• Alexander Zvegintsev (@azvegint - Reviewer)
• Abhishek Kumar (@kumarabhi006 - Committer)
• Sergey Bylokhov (@mrserb - Reviewer)

Reviewing

Using git

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

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

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 17081

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

Using diff file

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

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back tr! 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]

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

[mlbridge]

Webrevs

• 03: Full - Incremental (262ba9df)
• 02: Full - Incremental (67a8709e)
• 01: Full - Incremental (c72d9295)
• 00: Full (925b1b06)

[mrserb]

This is happening in linux
Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

[TejeshR13]

This is happening in linux
Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).

[aivanov-jdk]

This is happening in linux
Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).

Renjith @Renjithkannath worked on a similar bug, JDK-8256639: Test javax/swing/JPopupMenu/7160604/bug7160604.java fails on Ubuntu, and he reproduced the problem on macOS too, yet you have to make popups lightweight, they're heavyweight on macOS by default.

He tracked it down to the same root cause. His suggested fix was very similar to the one that @TejeshR13 proposes here. I wasn't convinced at that time that it was the best fix but I hadn't had time to look into it further.

Neither have I looked at this code review thoroughly yet.

Unfortunately, JDK-8256639 cannot be opened because it contains confidential information in its description.

[TejeshR13]

This is happening in linux
Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).

Renjith @Renjithkannath worked on a similar bug, JDK-8256639: Test javax/swing/JPopupMenu/7160604/bug7160604.java fails on Ubuntu, and he reproduced the problem on macOS too, yet you have to make popups lightweight, they're heavyweight on macOS by default.

He tracked it down to the same root cause. His suggested fix was very similar to the one that @TejeshR13 proposes here. I wasn't convinced at that time that it was the best fix but I hadn't had time to look into it further.

Neither have I looked at this code review thoroughly yet.

Unfortunately, JDK-8256639 cannot be opened because it contains confidential information in its description.

Yeah, looks like both the issue has the same root cause... As per my analysis in bufferStrategyManager the Graphics used is bsg rather than what is passed down from Component. I confirmed the root cause by passing down the component Graphics to Offscreen painting where the issue didn't reproduce. Hence clearing the bsg Graphics solves the issue.

[openjdk]

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

8187759: Background not refreshed when painting over a transparent JFrame

Reviewed-by: azvegint, abhiscxk, serb

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

• 69a11c7: 8326222: Fix copyright year in src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
• 9fbcc00: 8326127: JFR: Add SafepointCleanupTask to hardToTestEvents of TestLookForUntestedEvents
• 7d32a1a: 8326111: JFR: Cleanup for JFR_ONLY
• a3d7f9f: 8326126: Update the java manpage with the changes from JDK-8322478
• 20a25f6: 8326067: Remove os::remap_memory and simplify os::map_memory
• 5c5a282: 8325950: Make sure all files in the JDK pass jcheck
• 8668198: 8325972: Add -x to bash for building with LOG=debug
• a19314b: 8326101: [PPC64] Need to bailout cleanly if creation of stubs fails when code cache is out of space
• f6d7e30: 8294977: Convert test/jdk/java tests from ASM library to Classfile API
• 82609b1: 8326112: Javadoc snippet for Linker.Option.captureCallState is wrong
• ... and 191 more: https://git.openjdk.org/jdk/compare/85e320121e433da6fcf2d96a5a3d6c1520a88cb9...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.

[TejeshR13]

@azvegint @mrserb I have created two separate issue for windows and mac for the test failures.

1. https://bugs.openjdk.org/browse/JDK-8326026
2. https://bugs.openjdk.org/browse/JDK-8326027

[TejeshR13]

/integrate

[openjdk]

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

• d5f3d5c: 8326201: [S390] Need to bailout cleanly if creation of stubs fails when code cache is out of space
• d31fd78: 8325496: Make TrimNativeHeapInterval a product switch
• 27003b5: 8326090: Rename jvmti_aod.h
• 36246c9: 8326233: Utils#copySSLParameters loses needClientAuth Setting
• 14f9aba: 8326371: [BACKOUT] Clean up NativeCompilation.gmk and its newly created parts
• 1bd91cd: 8325963: Clean up NativeCompilation.gmk and its newly created parts
• 4d50ee6: 8326368: compare.sh -2bins prints ugly errors on Windows
• 221fbfb: 8320002: Remove obsolete CDS check in Reflection::verify_class_access()
• d2590c6: 8325730: StringBuilder.toString allocation for the empty String
• aa792ea: 8164094: javadoc allows to create a @link to a non-existent method
• ... and 211 more: https://git.openjdk.org/jdk/compare/85e320121e433da6fcf2d96a5a3d6c1520a88cb9...master

Your commit was automatically rebased without conflicts.

[openjdk]

@TejeshR13 Pushed as commit 04d43c4.

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