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