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

Sergey Bylokhov Sergey.Bylokhov at oracle.com
Thu Dec 20 17:52:50 UTC 2012


20.12.2012 14:12, Sergey Bylokhov wrote:
> 20.12.2012 13:49, Jim Graham wrote:
>> More to the point, if you substitute a 0x0 clip when an incoming clip 
>> is an empty rectangle then it will always be empty under any kind of 
>> transform.  This could be done by performing a "max(w,0);max(h,0);" 
>> operation on the incoming data.  Once a clip is accepted as 
>> non-empty, then I think the current code will adequately deal with 
>> flipped transforms, won't it?
> Yes, but with one exception. What to do with getClip:untransformShape 
> methods in this case, it executes the reverse transformation.
> The question is: if the incoming clip is an empty how to store it? If 
> we did not transform incoming clip, we should change 
> getClip/clip/untransformShape + some flag which should indicate that 
> incoming clip(not a result of transformation) was empty.
Another solution: don't use transformShape/untransformShape in the 
set/get methods. store usrClip as is, and transform usrClip->usrClipTmp 
in validateCompClip().
In this case setters/getters will become much simpler.
>>
>>             ...jim
>>
>> On 12/19/2012 8:47 PM, Jim Graham wrote:
>>> Hi Sergey,
>>>
>>> This is all a lot more complicated than I think it needs to be. Why not
>>> just detect incoming empty rectangles and force an empty composite clip
>>> in that case?  No heuristics necessary...
>>>
>>>              ...jim
>>>
>>> On 12/15/2012 9:26 AM, Sergey Bylokhov wrote:
>>>> Hi, Jim.
>>>> Could you please review the updated version of the fix:
>>>> http://cr.openjdk.java.net/~serb/8004859/webrev.01
>>>> 14.12.2012 0:40, Jim Graham wrote:
>>>>> This fix breaks other behavior.
>>>>>
>>>>> You need to use setFrameFromDiagonal on the results of the transform
>>>>> because a flip or rotation can cause the transformed points to be
>>>>> unordered and setFFD will sort them as they need to be. It is the
>>>>> incoming rectangle that needs to be checked for being empty, not the
>>>>> results of the transform.
>>>> In the new version I restore coordinates relation, if it were changed
>>>> during transform.
>>>> Swap needed:
>>>>   - If the user provide incorrect rectangle and after 
>>>> transformation we
>>>> get correct rectangle.
>>>>   - If the user provide correct rectangle and after transformation we
>>>> get incorrect rectangle.
>>>>>
>>>>> The case that will fail with this fix is setting the clip to a valid
>>>>> rectangle in a coordinate system that is rotated by a multiple of 90
>>>>> degrees or is flipped horizontally or vertically. Those cases will
>>>>> result in an empty clip, but the clip was not empty coming in...
>>>>>
>>>>>             ...jim
>>>>>
>>>>> On 12/13/2012 3:08 AM, Sergey Bylokhov wrote:
>>>>>> Hello,
>>>>>> Please review the fix for jdk 8.
>>>>>> Change description:
>>>>>> 1 transformShape now symmetric to untransformShape()
>>>>>> (setFrameFromDiagonal was removed).
>>>>>> 2 getClipBounds now always uses getBounds2D which does not return 
>>>>>> empty
>>>>>> Rectangle if the userclip has negative width or height.
>>>>>>
>>>>>> Note that if the userclip has negative width or height, our real
>>>>>> graphic
>>>>>> clip will be empty/no-area. This wasn't true before the fix for the
>>>>>> scaled graphics.
>>>>>>
>>>>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004859
>>>>>> Webrev can be found at:
>>>>>> http://cr.openjdk.java.net/~serb/8004859/webrev.00
>>>>>>
>>>>
>>>>
>
>


-- 
Best regards, Sergey.




More information about the 2d-dev mailing list