<Swing Dev> Fw: review request for 6899434: Add affine transformsupport to JLayer

[Artem Ananiev]

On 2/11/2010 3:24 PM, Alexander Potochkin wrote:
> Hello Artem
>
>>
>> As a side effect, this would give the developers a flexibility to use
>> non-affine transforms. They will even be able to use different
>> transforms for forward and reverse operations, but I doubt anyone will
>> want this (or we could add an explicit warning to JavaDoc about this).
>
> a small remark:
>
> JLayer is planned to only support the features from Graphics2D
> because Swing Components are tightly bound with this class
>
> Graphics2D works with AffineTransforms only
> and that's why JLayer.setTransform(AffineTransforms)
> mirrors the existing method from 2D
>
> If in JDK 8 it will be a new method like
>
> Graphics2D.setNonAffineTransform() or whatever,
> JLayer will add a similar method
>
> but for this moment JLayer.setTransform(AffineTransforms)
> is all we want to have

I haven't mentioned JLayer at all. When we make some of our API 
public/protected, developers will be able to implement their own 
components with transformations of any kind - this is what I wrote about.

Thanks,

Artem

> Thanks
> alexp
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/8/2010 2:27 PM, Piet Blok wrote:
>>> Hi Artem,
>>>
>>> To demonstrate the implemention via the AWTAccessor pattern, I created a
>>> version 2 implementation:
>>>
>>> http://www.pbjar.org/OpenJDK/6899434/version-2/webrev/
>>>
>>> This implementation is much cleaner than the original one.
>>>
>>> Looking forward for yout comments,
>>> Piet
>>>
>>>
>>>
>>>> Hi Artem,
>>>>
>>>> The problem with making existing methods public is that it solves only
>>>> half of the problem at hand:
>>>>
>>>> 1) Locate the correct component (can be solved)
>>>>
>>>> 2) Recalculating the mouse point from rendered space to layout space
>>>> is not solved because the locating methods only return a component.
>>>> Recalculation is needed to correctly set a mouse point in the new
>>>> events, relative to the target component.
>>>>
>>>> In my proposed implementation the shift caused by transformations is
>>>> stored when looking up the target (for future use: creating new events
>>>> from the original event). This future is quite an immediate future
>>>> because creating a new event from an existing event will always be
>>>> directly preceded by looking up that target event.
>>>>
>>>> An alternative would be to again iterate through the hierarchy and do
>>>> the transformations. This must be done in LightweightDispatcher in the
>>>> methods:
>>>>
>>>> 1) retargetMouseEvent (an inverse transform is needed, so the new
>>>> Container method getConvertedPoint can be used)
>>>>
>>>> 2) eventDispatched. Unfortunately here an ordinary transform is
>>>> needed, so a second new Container method must be defined that does an
>>>> ordinary transform.
>>>>
>>>> But.... a completely different approach is also possible. I did this
>>>> in an earlier version, so I know that it works. With this approach no
>>>> new public or protected methods need to be introduced and no existing
>>>> methods need to go public or protected. All remains private or package
>>>> private.
>>>>
>>>> That approach is as follows:
>>>>
>>>> 1) Define the AffineTransform as a private field in Component.
>>>>
>>>> 2) Use the AWTAccessor pattern to make the transform available in
>>>> Container and LightweightDispatcher and in swing classes.
>>>>
>>>> 3) In Container and LightweightDispatcher, get the transform and do
>>>> transformations when needed.
>>>>
>>>> In my opinion, the solution with the AWTAccessor pattern is the
>>>> cleanest. However, it requires Component and AWTAccessor to be touched.
>>>>
>>>> Please let me know what you think.
>>>>
>>>> Piet
>>>>
>>>>
>>>>
>>>>> Hi, Piet,
>>>>>
>>>>> I haven't looked through the entire webrev and inspected mostly an
>>>>> AWT part of the fix. A question is whether it's possible to get rid
>>>>> of the new "conversionShift" field in Container, to make
>>>>> transformations support really stateless?
>>>>>
>>>>> Another option to consider is to make some of the existing methods
>>>>> (e.g. getMouseEventTargetImpl()) public instead of introducing new
>>>>> ones.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 1/28/2010 8:21 PM, Piet Blok wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> review request for 6899434: Add affine transform support to JLayer
>>>>>>
>>>>>> The webrev: http://www.pbjar.org/OpenJDK/6899434/webrev/
>>>>>>
>>>>>> The patch covers all the requested functionality. It is
>>>>>> concentrated in
>>>>>> JLayer class, keeping in mind to affect the library as little as
>>>>>> possible.
>>>>>>
>>>>>> 1) A setter and getter for the transform in JLayer
>>>>>>
>>>>>> 2) The paint method in JLayer has been adapted to use the transform
>>>>>>
>>>>>> 3) RepaintManager has been adapted to propagate repaint requests from
>>>>>> the view or any of its children to the top level JLayer and have the
>>>>>> dirty region transformed.
>>>>>>
>>>>>> 4) java.awt.Container and java.awt.LightweightDispatcher (both in the
>>>>>> same source) have been adapted to redispatch MouseEvents to the
>>>>>> intended
>>>>>> target component. The lookup for the component that provides a custon
>>>>>> cursor has also been adapted.
>>>>>>
>>>>>> 5) To enable Container to do necessary reculculations, a protected
>>>>>> method has been introduced that will be overridden by JLayer:
>>>>>> protected Point getConvertedPoint(Point point).
>>>>>> (If someone can suggest a better name for this method I'm glad to
>>>>>> hear)
>>>>>>
>>>>>> 6) A package private method in SwingUtilities has been added that
>>>>>> helps
>>>>>> JPopupMenu and ToolTipManager to find the correct popup location.
>>>>>> JPopupMenu and ToolTipManager have been changed to use this new
>>>>>> method
>>>>>> in their calculations.
>>>>>>
>>>>>> 7) Two jtreg tests have been added.
>>>>>>
>>>>>> Looking forward for comments.
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>