On 6/24/2016 1:14 AM, Phil Race wrote:
So .. question to Alexandr :
JComponent.paintChildren() is the only place in the JDK that consumes
this API.
Is this causing a particular problem with Swing hi-dpi - other than
repainting in cases that maybe didn't need it ?
This is used, for example, for internal frames dragging. An internal
frame is just copied as a whole image so only small areas near the
internal frame should be repainted.
The current case where hit hitClip() fails for scale 1.5 causes
whole internal frame repainting on Windows with 150% scale.
Swing can implement its own clip intersection algorithm for this
special case.
I can close the JDK-8160124 as not an issue.
Thanks,
Alexandr.
-phil.
On 6/23/2016 3:00 PM, Jim Graham wrote:
Since "return true" would be a compliant implementation of
Graphics.hitClip(), this is not a bug...
Read the documentation, it is allowed to use fast math that can
return true when technically the answer is false...
...jim
On 6/23/16 5:04 AM, Alexandr Scherbatiy wrote:
Hello,
Could you review the fix:
bug: https://bugs.openjdk.java.net/browse/JDK-8160124
webrev: http://cr.openjdk.java.net/~alexsch/8160124/webrev.00
Let's set the clip [x=5, y=5, width=5, height=5] to a graphics and
call the hitClip() with the passed rectangle [x=0,
y=0, width=5, height=5].
The result is false for the graphics with scale 1 and true if the
scale is floating point 1.5.
This is because the transformed clip which has floating point
bounds [7.5, 7.5, 7.5, 7.5] for the scale 1.5 has bounds
with rounded down upper-left and rounded up lower-right corners [7,
7, 8, 8] which now intersects with the transformed
rectangle [0, 0, 7.5, 7.5].
The proposed fix adds additional check for the user clip and the
user rectangle intersection if the intersection with
the region clip passes.
Thanks,
Alexandr.
