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

[Jim Graham]

Hi Sergey,

On 12/20/2012 4:42 PM, Sergey Bylokhov wrote:
> Hi, Jim.
> 21.12.2012 3:54, Jim Graham wrote:
>> Hi Sergey,
>>
>> The getClip methods don't claim to return the exact same shape that
>> the user handed in - it just has to cover the territory covered by the
>> clip.  x,y,-N,-M covers the same territory as x,y,0,0 so it would be
>> fine to substitute that value in its place.  It is arguable whether it
>> matters if we convert x,y,+N,-M to x,y,+N,0 or x,y,0,0 since both
>> rectangles cover no ground. Also, preserving the x,y is questionable
>> since any 0-dimensioned rectangle covers no ground and is equally
>> representative of the fact that the clip is empty.

> Yes, they covers the same territory, but how we can check, that the
> these shapes equivalent? Because equals return false for them. Note that
> equals of the Area states about

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.

>> 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.

>> 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