On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov <s...@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

Reply via email to