8264475: CopyArea ignores clip state in metal rendering pipeline

[jayathirthrao]

In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea.

---

Progress

• Change must not contain extraneous whitespace
• Commit message must refer to an issue
• Change must be properly reviewed

Issues

• JDK-8264475: CopyArea ignores clip state in metal rendering pipeline
• JDK-8251036: SwingSet2 - Dragging internal frame inside jframe leaves artifacts with MetalLookAndFeel

Reviewers

• Ajit Ghaisas (@aghaisas - Committer) ⚠️ Review applies to 9b4a90a
• Prasanta Sadhukhan (@prsadhuk - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.java.net/jdk pull/3283/head:pull/3283
$ git checkout pull/3283

Update a local copy of the PR:
$ git checkout pull/3283
$ git pull https://git.openjdk.java.net/jdk pull/3283/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 3283

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

Using diff file

Download this PR as a diff file:
https://git.openjdk.java.net/jdk/pull/3283.diff

[bridgekeeper]

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

@jayathirthrao The following label will be automatically applied to this pull request:

• 2d

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 (91e068b9)
• 02: Full - Incremental (9b4a90ab)
• 01: Full - Incremental (3e1ba4c9)
• 00: Full (d72f9490)

[jayathirthrao]

/issue add JDK-8251036

[openjdk]

@jayathirthrao
Adding additional issue to issue list: 8251036: SwingSet2 - Dragging internal frame inside jframe leaves artifacts with MetalLookAndFeel.

[aghaisas]

I tested this fix. No regressions were observed.

Using MTLBlitCommandEncoder is intuitive when metal resource copying needs to be done.
I suggest to add a comment (may be as a method description or in code where we do the actual copy) to mention why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

[jayathirthrao]

I tested this fix. No regressions were observed.

Using MTLBlitCommandEncoder is intuitive when metal resource copying needs to be done.
I suggest to add a comment (may be as a method description or in code where we do the actual copy) to mention why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

Thanks Ajit for testing the fix. I have added comment mentioning why we use MTLRenderCommandEncoder and not MTLBlitCommandEncoder.

[openjdk]

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

8264475: CopyArea ignores clip state in metal rendering pipeline
8251036: SwingSet2 - Dragging internal frame inside jframe leaves artifacts with MetalLookAndFeel

Reviewed-by: aghaisas, psadhukhan

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

• c04a743: 8264557: Incorrect copyright year for test/micro/org/openjdk/bench/java/lang/MathBench.java after JDK-8264054
• 4b19771: 8264150: CDS dumping code calls TRAPS functions in VM thread
• 1dc75e9: 8264538: Rename SystemDictionary::parse_stream
• 80681b5: 8264546: Dependencies: Context class is always an InstanceKlass
• fdfa1dd: 8264306: Non deterministic generation of java/lang/invoke/MemberName.class
• 011f6d1: 8264223: CodeHeap::verify fails extra_hops assertion in fastdebug test
• 0696fd0: 8263496: MetalHighContrastTheme.getControlHighlight cleanup
• 6cf1095: 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent
• d2df9a7: 8264331: Use the blessed modifier order in jdk.compiler
• 0228734: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows
• ... and 17 more: https://git.openjdk.java.net/jdk/compare/928fa5b5f967eb8f1dfec64ba79ef0177df15230...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.

[mrserb]

Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap?

[jayathirthrao]

Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap?

I am not getting what do you mean by 'new "round trip" '. Please elaborate.
Regarding performance metrics i have captured the details in the bug and there is no degradation.

[mrserb]

I am not getting what do you mean by 'new "round trip" '. Please elaborate.
Regarding performance metrics i have captured the details in the bug and there is no degradation.

The new code path which takes care of the clip, if there is no degradation means that we get it for free?

[jayathirthrao]

I am not getting what do you mean by 'new "round trip" '. Please elaborate.
Regarding performance metrics i have captured the details in the bug and there is no degradation.

The new code path which takes care of the clip, if there is no degradation means that we get it for free?

Before this change we used to get blitEncoder from same commandbuffer(and same CommandQueue) as we are doing now. And then commit the commandbuffer, so from computational perspective we are not holding or doing anything extra in new implementation. We need to use appropriate encoder(where scissor is set) to honour clip in copyArea.

Since we are not seeing any difference in performance numbers (especially in swingmark where we do lot of scrolling/copyArea) we are basically getting clipping in copyArea without any degradation. Also in Netbeans i have done good amount scrolling test and i dont see any degradation. Also i expected improvement in performance (we are seeing little improvement in swingmark numbers) because we are actually doing less amount of copy operation now.

[mrserb]

We need to use appropriate encoder(where scissor is set) to honour clip in copyArea.

It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough.

[jayathirthrao]

We need to use appropriate encoder(where scissor is set) to honour clip in copyArea.

It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough.

Exactly i suspect we are not hitting threshold of GPU computing in our tests. If we hit GPU threshold with larger clip bounds i expect performance to be on higher side after the fix.

[jayathirthrao]

@mrserb Are there any more inputs/review comments?

[mrserb]

nop, it is fine.

[jayathirthrao]

/integrate

[openjdk]

@jayathirthrao Since your change was applied there have been 54 commits pushed to the master branch:

• f084bd2: 8262355: Support for AVX-512 opmask register allocation.
• 0780666: 8254050: HotSpot Style Guide should permit using the "override" virtual specifier
• f259eea: 8264393: JDK-8258284 introduced dangling TLH race
• 9b2232b: 8264123: add ThreadsList.is_valid() support
• e8eda65: 8264664: use text blocks in javac module tests
• cec66cf: 8264572: ForkJoinPool.getCommonPoolParallelism() reports always 1
• 9c283da: 8264662: ProblemList vmTestbase/jit/escape/AdaptiveBlocking/AdaptiveBlocking001/AdaptiveBlocking001.java on win-x64 with ZGC
• eb0ac86: 8264655: Minor internal doc comment cleanup
• 3991b32: 8264539: Improve failure message of java/nio/file/WatchService/SensitivityModifier.java
• 4133ded: 8264658: ProblemList javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java on linux-x64
• ... and 44 more: https://git.openjdk.java.net/jdk/compare/928fa5b5f967eb8f1dfec64ba79ef0177df15230...master

Your commit was automatically rebased without conflicts.

Pushed as commit 0039c18.

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