On 08/02/2016 10:36 AM, Sergey Bylokhov wrote:
On 27.07.16 1:56, Jim Graham wrote:
Rectangle2D rClip = (Rectangle2D) usrClip;
int x0 = (int) Math.ceil(rClip.getMinX() - 0.5);
int y0 = (int) Math.ceil(rClip.getMinY() - 0.5);
int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5);
int x1 = (int)
On 27.07.16 1:56, Jim Graham wrote:
Rectangle2D rClip = (Rectangle2D) usrClip;
int x0 = (int) Math.ceil(rClip.getMinX() - 0.5);
int y0 = (int) Math.ceil(rClip.getMinY() - 0.5);
int x1 = (int) Math.ceil(rClip.getMaxX() - 0.5);
int x1 = (int) Math.ceil(rClip.getMaxY() - 0.5);
clipRegion =
Ah, this is an issue of what an empty rectangle means.
Filling 1.5,1.5,0,0 produces no output because it has no interior.
But, stroking 1.5,1.5,0,0 can produce output because it is simply a
rectangle that spins in place.
As a result there are really 3 different containment properties for a
What does the compClip end up being in that case?
...jim
On 7/4/16 1:12 AM, Sergey Bylokhov wrote:
On 01.07.16 2:49, Jim Graham wrote:
How is it returning true? If the clip really is empty, then
intersectsQuickCheck() should never return true. Or are you saying that
On 01.07.16 2:49, Jim Graham wrote:
How is it returning true? If the clip really is empty, then
intersectsQuickCheck() should never return true. Or are you saying that
an empty clip shape produces a non-empty composite clip region?
This code will test such situation:
BufferedImage
How is it returning true? If the clip really is empty, then
intersectsQuickCheck() should never return true. Or are you saying that
an empty clip shape produces a non-empty composite clip region?
...jim
On 06/30/2016 10:02 AM, Sergey Bylokhov wrote:
It looks strange
It looks strange that the empty clip became "non-empty"(at least hitClip
reports this) when we apply transform to it, no? I guess that at the
beginning of hitClip() we should check that the clip.isEmpty(), and we
should return "false" in this case(I think this is not strictly related
to this
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
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
Think of this method as asking:
I don't want you to waste a lot of time, but tell me if it is silly for me to even consider rendering something with
these bounds.
And the answer is either "Oh, yeah, it is inconceivable that those bounds would be rendered", or "Not sure, maybe, just
render it
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
On 06/23/2016 05: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()
12 matches
Mail list logo
