On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote:
> Some of our code assumes that the native system(XRender, D3D, OGL) makes some
> effective optimizations, but in some cases, we can do better.
>
> One of the areas for improvement is direct blitting. If the source is much
> bigger than th
On Thu, 10 Sep 2020 22:47:53 GMT, Sergey Bylokhov wrote:
> Some of our code assumes that the native system(XRender, D3D, OGL) makes some
> effective optimizations, but in some cases, we can do better.
>
> One of the areas for improvement is direct blitting. If the source is much
> bigger than th
Some of our code assumes that the native system(XRender, D3D, OGL) makes some
effective optimizations, but in some cases, we can do better.
One of the areas for improvement is direct blitting. If the source is much
bigger than the destination we should not try to copy to the non-existent area
and
On 29.08.2020 12:01, Philip Race wrote
I'm not sure I get the comment about the intersection operation causing
performance problems.
Are you referring to the cost of that intersection operation itself, or some
downstream consequence ?
Yes, I am talking about the cost of intersection itself.
I note that you change the signature of blitSurfaceData to private.
I think this is fine. Since it is only used in this class I imagine
whatever reason
it was supposed it might need to be over-ridden has never arisen ..
But I still had to first go check that it isn't actually used elsewhere !
Hello.
Please review the fix for jdk/client.
Bug: https://bugs.openjdk.java.net/browse/JDK-8252070
Fix: http://cr.openjdk.java.net/~serb/8252070/webrev.01
Some of our code assumes that the native system(XRender, D3D, OGL) makes some
effective optimizations, but in some cases, we can do better.