[OpenJDK 2D-Dev] [8] Request for review: 8004859 Graphics.getClipBounds/getClip return difference nonequivalent bounds, depending from transform.

[Sergey Bylokhov]

21.12.2012 6:05, Sergey Bylokhov пишет:
> Hi, Jim.
> 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 
>> contract.
>>
>> - 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 
>> comparator.
> 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 
>>> test.
>>
>> 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.
typo:  Also there is the difference in the real clip, if we change type 
from the empty Rectangle to the empty Rectangle2D, the real clip will 
become 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...
>>
>>             ...jim
>
>
> -- 
> Best regards, Sergey.


-- 
Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20121221/cbda78e2/attachment.html>