I suspect the answer is that as long as Swing/AWT use APIs that have integer coordinates, there will be cases where this
hit testing might be able to know the answer in floating point coordinates, but lose the ability to answer accurately
when everything is turned into integers - which often involves ceil/floor operations that expand bounding boxes. In the
case of 150% rendering for Windows, sometimes you can't accurately describe the pixels you will be rendering with enough
precision in integer coordinates...
...jim
On 6/23/16 3:14 PM, 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 ?
-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.
