[OpenJDK 2D-Dev]  Request for review: 8004859 Graphics.getClipBounds/getClip return difference nonequivalent bounds, depending from transform.
Sergey.Bylokhov at oracle.com
Fri Dec 21 02:05:09 UTC 2012
21.12.2012 4:59, Jim Graham wrote:
> The Object.equals() method is not intended to compare geometries.
> While Area.equals() attempts to perform geometric comparison I think
> that was a bad idea in retrospect for many reasons:
> - In practice you can only really compare within a tolerance due to
> the many ways for computations to every so slightly shift the results
> - There is no decent way to satisfy the equals/hashcode contract with
> such a comparison so Area is forever broken with respect to that
> - It's a complicated test that can only serve to convince developers
> to invite performance drains into their code by making them think it
> is a reasonable thing to compare.
> For testing we should probably use Shape.contains() to verify answers
> for rectangle arguments and if we want to perform verification on
> arbitrary shape arguments then we'd need to write our own fuzzy
But why fix is incorrect? It just use the same code as sffd for the
correct shapes and have additional code for incorrect. Only
conditionchanged from width/height should be positive, to
width/height should be the same direction as incoming rectangle.
>>> There isn't even any guarantee that we will hand them back a rectangle
>>> from getClip().
>> One of the jck tests expect this, but I think that this is the wrong
> There is nothing in the documentation that guarantees a specific type
> returned from the method. If a JCK test was written to expect a
> Rectangle from the method then that is a separate problem that we'll
> have to address at some point. For now I'm only suggesting modifying
> the process for negative-empty rectangles. Does that trigger the JCK
> failure? If so, we are still satisfying the documented spec and so we
> will simply have to confince JCK to allow this exception.
Problem in jck come from the fact that Rectangle differs from
Rectangle2d. Note that everything is ok if graphics is not transformed
or just translated. But if we scale graphics we get:
1 getClip() return non equivalent object.
2 getClipBounds for Rectangle return it as is, but for Rectangle2D it is
call getBounds, which return an empty bounds or wrong bounds if
rectangle2d was normalized by sffd.
3 Some tests expects class equivalence between set/get clip. I'll
prepare CR for them soon.
Also there is the difference in the real clip, if we use type for the
empty Rectangle to Rectangle2D the real clip became correct.
All these issues are carried out in the testcase.
>>> After all, if you end up in the drop through case then we hand the
>>> paths to Area to do intersections and Area will do all sorts of
>>> surgery on the geometry.
>> But I sure this area will be equal to the user's clip?
> For all practical purposes it should be, but not only will the Area
> code encapsulate the answer in a different class (even if the result
> is a rectangle), it may reverse the order of the segments, it may
> represent the area as two separate rectangles that abut each other in
> a way that they are equivalent to one larger rectangle, but the Area
> code failed to notice that optimization, etc. All it will guarantee
> is that it returns a shape that describes the same interior, it will
> make no guarantees about minimalism or association of segments...
Best regards, Sergey.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the 2d-dev