[OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4]
Jayathirth D V
jdv at openjdk.java.net
Sun Apr 4 10:04:06 UTC 2021
On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
>>> > 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.
>
>> 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.
@mrserb Are there any more inputs/review comments?
-------------
PR: https://git.openjdk.java.net/jdk/pull/3283
More information about the 2d-dev
mailing list