From Anthony.Petrov at Sun.COM  Mon Feb  1 15:19:36 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Mon, 01 Feb 2010 18:19:36 +0300
Subject: <Swing Dev> <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
Message-ID: <4B66F108.6010609@sun.com>

Hi Clemens, Damjan,

[ also copying the swing-dev@ list ]

AFAIK, there currently nobody working on such an enhancement to the 
Swing GTK L&F implementation. This L&F is by far not the fastest one out 
there, so any improvement is very welcome.

If either of you could help with developing a fix, that would be very 
much appreciated.

--
best regards,
Anthony

On 1/30/2010 7:47 PM Clemens Eisserer wrote:
> Hi Damjan,
> 
>> The number of roundtrips isn't such a problem, the number is pixels
>> is. 2 NxM pixmaps have the same number of pixels in total as an Nx2M
>> or 2NxM pixmap, so little time is saved.
> 
> Sure the amount of data stays the same - however for (most modern)
> video drivers which place their pixmaps in vram it does make a
> difference.The whole situation is quite ugly :-/
> 
>> Anyway, when last I heard the solution to this was to subclass GDK
>> drawing functions so they draw with the alpha channel in the first
>> place, instead of the double drawing without alpha and then mixing
>> pixmaps to recover it. Anyone working on this?
> 
> Hmm, I guess the best thing would be to get GTK's broken theme API
> right, to draw on a cairo-context instead of a GdkDrawalbe.
> 
> I submited patches for rfc some time ago, but nobody really looked at
> it. To me it seems GTK is quite dead.
> When I brought that topic up again, it was mentioned that the work is
> obsolete because GTK+3 will have an all new-any-shiny theming API
> which will be perfect in any aspect.
> 
> However they are talking about GTK+3 for about 2,5 years now, with no outcome.
> 
> Hmm, I am starting to get personal again ;)
> 
> - Clemens


From damjan.jov at gmail.com  Mon Feb  1 15:28:13 2010
From: damjan.jov at gmail.com (Damjan Jovanovic)
Date: Mon, 1 Feb 2010 17:28:13 +0200
Subject: <Swing Dev> <AWT Dev> Question about GtkLnF implementation
In-Reply-To: <4B66F108.6010609@sun.com>
References: <194f62551001300743u40c9b112y1766eed6369a7c2f@mail.gmail.com>
	<9e89675b1001300813j7e993449x23b5231b9c0c0648@mail.gmail.com>
	<194f62551001300847p3dc450c1yc1610dead2c94222@mail.gmail.com>
	<4B66F108.6010609@sun.com>
Message-ID: <9e89675b1002010728p6908b8aak402a7fa997d02916@mail.gmail.com>

Hi Anthony, Clemens, others

There's an interesting comment, quoted below, in the evaluation of
http://bugs.sun.com/view_bug.do?bug_id=6286734

---BEGIN QUOTE---
I have an idea of impoving overall GTK LAF performance by implementing
own gdk backend which would draw gtk widgets directly to
X11SurfaceData backing buffer.
It improves GTK LAF performance dramatically especially on remote
hosts (up to 20 times).
Together with some minor changes it would be a better solution for this "bug"
Uncommit it from Mustang becasue I'm getting late with this feature.
Posted Date : 2006-03-27 13:03:58.0
---END QUOTE---

Who wrote this (I suspect Kirill Kirichenko for some reason) and is
this code still around? It would really help to see it.

Thank you
Damjan


On Mon, Feb 1, 2010 at 5:19 PM, Anthony Petrov <Anthony.Petrov at sun.com> wrote:
> Hi Clemens, Damjan,
>
> [ also copying the swing-dev@ list ]
>
> AFAIK, there currently nobody working on such an enhancement to the Swing
> GTK L&F implementation. This L&F is by far not the fastest one out there, so
> any improvement is very welcome.
>
> If either of you could help with developing a fix, that would be very much
> appreciated.
>
> --
> best regards,
> Anthony
>
> On 1/30/2010 7:47 PM Clemens Eisserer wrote:
>>
>> Hi Damjan,
>>
>>> The number of roundtrips isn't such a problem, the number is pixels
>>> is. 2 NxM pixmaps have the same number of pixels in total as an Nx2M
>>> or 2NxM pixmap, so little time is saved.
>>
>> Sure the amount of data stays the same - however for (most modern)
>> video drivers which place their pixmaps in vram it does make a
>> difference.The whole situation is quite ugly :-/
>>
>>> Anyway, when last I heard the solution to this was to subclass GDK
>>> drawing functions so they draw with the alpha channel in the first
>>> place, instead of the double drawing without alpha and then mixing
>>> pixmaps to recover it. Anyone working on this?
>>
>> Hmm, I guess the best thing would be to get GTK's broken theme API
>> right, to draw on a cairo-context instead of a GdkDrawalbe.
>>
>> I submited patches for rfc some time ago, but nobody really looked at
>> it. To me it seems GTK is quite dead.
>> When I brought that topic up again, it was mentioned that the work is
>> obsolete because GTK+3 will have an all new-any-shiny theming API
>> which will be perfect in any aspect.
>>
>> However they are talking about GTK+3 for about 2,5 years now, with no
>> outcome.
>>
>> Hmm, I am starting to get personal again ;)
>>
>> - Clemens
>


From c.cerbo at gmail.com  Mon Feb  1 21:31:12 2010
From: c.cerbo at gmail.com (Costantino Cerbo)
Date: Mon, 1 Feb 2010 22:31:12 +0100
Subject: <Swing Dev> swing-dev Digest, Vol 34, Issue 1
In-Reply-To: <mailman.9.1265054401.3340.swing-dev@openjdk.java.net>
References: <mailman.9.1265054401.3340.swing-dev@openjdk.java.net>
Message-ID: <6fbbec31002011331s6522d783o9aaeabac8977ad17@mail.gmail.com>

> Date: Mon, 01 Feb 2010 18:19:36 +0300
> From: Anthony Petrov <Anthony.Petrov at Sun.COM>
> AFAIK, there currently nobody working on such an enhancement to the
> Swing GTK L&F implementation. This L&F is by far not the fastest one out
> there, so any improvement is very welcome.

If Oracle will invest more money on Java and Solaris, as Larry Ellison
said, they should invest also on the GTK L&F!
Isn't Gnome the default GUI Environment on the (now) Oracle Operating
System! ;-)

By the way, did you have the time to take a look to my last patch (Bug
6913179) and experiment a little bit to solve the problem with the
EDT?
I spent also yesterday some time but without success :-(

Thank you very much,
Costantino


From arafat877 at gmail.com  Tue Feb  2 17:27:42 2010
From: arafat877 at gmail.com (arafat bouchafra)
Date: Tue, 2 Feb 2010 17:27:42 +0000
Subject: <Swing Dev> Subscription
Message-ID: <d5d0e8e01002020927t6f0500c2y509b59a91b1ac26c@mail.gmail.com>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20100202/cff6de9f/attachment.html>

From arafat877 at gmail.com  Wed Feb  3 09:42:45 2010
From: arafat877 at gmail.com (arafat bouchafra)
Date: Wed, 3 Feb 2010 09:42:45 +0000
Subject: <Swing Dev> swing-dev Digest, Vol 34, Issue 2
In-Reply-To: <mailman.17.1265140802.13438.swing-dev@openjdk.java.net>
References: <mailman.17.1265140802.13438.swing-dev@openjdk.java.net>
Message-ID: <d5d0e8e01002030142o5eeb51e7ia841e0f7d0f0492b@mail.gmail.com>

Hi !
I'm arafat bouchafra, a Moroccan software engineer, I like javaa very much,
but I don't know who's the future of java after sun was buying by oracle,
and yesterday 02/02/2010,Sang Shin say's the he leaves SUN/ORACLE, and here
is a short cut of an email the I received:

On Fri, Jan 29, 2010 at 4:42 AM, Sang Shin <sangshinpassion at gmail.com<mailto:
sangshinpassion at gmail.com>> wrote:


   As a result of recent Sun/Oracle merger, I've decided to
   leave Sun/Oracle and decided to pursue a career of teaching
   and consulting.


If persons like Sang Shin leaves Oracle, in your opinion what's the future
of java in the future ?

2010/2/2 <swing-dev-request at openjdk.java.net>

> Send swing-dev mailing list submissions to
>        swing-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://mail.openjdk.java.net/mailman/listinfo/swing-dev
> or, via email, send a message with subject or body 'help' to
>        swing-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>        swing-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of swing-dev digest..."
>
>
> Today's Topics:
>
>   1. Re:  swing-dev Digest, Vol 34, Issue 1 (Costantino Cerbo)
>   2.  Subscription (arafat bouchafra)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 1 Feb 2010 22:31:12 +0100
> From: Costantino Cerbo <c.cerbo at gmail.com>
> Subject: Re: <Swing Dev> swing-dev Digest, Vol 34, Issue 1
> To: swing-dev at openjdk.java.net, awt-dev at openjdk.java.net,
>        Anthony.Petrov at Sun.COM
> Message-ID:
>        <6fbbec31002011331s6522d783o9aaeabac8977ad17 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> > Date: Mon, 01 Feb 2010 18:19:36 +0300
> > From: Anthony Petrov <Anthony.Petrov at Sun.COM>
> > AFAIK, there currently nobody working on such an enhancement to the
> > Swing GTK L&F implementation. This L&F is by far not the fastest one out
> > there, so any improvement is very welcome.
>
> If Oracle will invest more money on Java and Solaris, as Larry Ellison
> said, they should invest also on the GTK L&F!
> Isn't Gnome the default GUI Environment on the (now) Oracle Operating
> System! ;-)
>
> By the way, did you have the time to take a look to my last patch (Bug
> 6913179) and experiment a little bit to solve the problem with the
> EDT?
> I spent also yesterday some time but without success :-(
>
> Thank you very much,
> Costantino
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 2 Feb 2010 17:27:42 +0000
> From: arafat bouchafra <arafat877 at gmail.com>
> Subject: <Swing Dev> Subscription
> To: swing-dev at openjdk.java.net
> Message-ID:
>        <d5d0e8e01002020927t6f0500c2y509b59a91b1ac26c at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20100202/cff6de9f/attachment-0001.html
>
> End of swing-dev Digest, Vol 34, Issue 2
> ****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/swing-dev/attachments/20100203/ce55bb23/attachment.html>

From arafat877 at gmail.com  Wed Feb  3 09:43:09 2010
From: arafat877 at gmail.com (arafat bouchafra)
Date: Wed, 3 Feb 2010 09:43:09 +0000
Subject: <Swing Dev> =?iso-8859-1?q?arafat_bouchafra_vous_invite_=E0_ouvri?=
	=?iso-8859-1?q?r_un_compte_de_messagerie_Google=2E?=
Message-ID: <d5d0e8e01002030143s4731c137l@mail.gmail.com>

J'utilise Gmail et j'ai pens? que tu aimerais l'essayer. Voici une
invitation pour cr?er un compte.

-----------------------------------------------------------------------
arafat bouchafra vous invite ? ouvrir un compte Gmail gratuit.

Pour accepter cette invitation et ouvrir votre compte, consultez la
page http://mail.google.com/mail/a-9cce9aa86c-808cd00f66-dbfd44c6571f5acf.

Une fois votre compte cr??, arafat bouchafra sera inform?(e) de votre
nouvelle adresse e-mail pour que vous puissiez rester en contact gr?ce
? Gmail?!

Si vous ne connaissez pas encore Gmail, sachez qu'il s'agit d'un
nouveau service de messagerie ?lectronique qui exploite la technologie
de recherche de Google et offre les fonctionnalit?s suivantes?:

- Plus de 2?700 m?ga-octets (deux giga-octets) d'espace de stockage gratuit.
- Recherche Google int?gr?e permettant de retrouver instantan?ment
n'importe quel message.
- Organisation automatique des messages et des r?ponses regroup?es en
"conversations".
- Protection puissante contre les spams gr?ce ? la technologie
innovante de Google.
- Aucune publicit? envahissante?! Seules de petites annonces
textuelles et des pages en rapport avec le texte de vos messages vous
sont pr?sent?es.

Pour plus d'informations sur Gmail avant de vous inscrire, consultez
la page suivante?:
http://mail.google.com/mail/help/intl/fr/benefits.html

Nous travaillons chaque jour ? l'am?lioration de Gmail. Dans le cadre
de ce processus, il est possible que nous vous contactions pour vous
demander vos impressions et vos ?ventuelles suggestions.  Nous
esp?rons que vous aimerez Gmail.  Nous, on l?aime?! Et nous
continuerons d'y apporter des am?liorations.

Merci,

L'?quipe Gmail

Si les URL de ce message ne fonctionnent pas, copiez-les et collez-les
ensuite dans la barre d'adresse de votre navigateur.


From sergey.malenkov at sun.com  Fri Feb  5 07:36:56 2010
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Fri, 05 Feb 2010 07:36:56 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6921057: REGRESSION: persistence
	delegate issue	on Windows and Linux against 5.u23b03/6u17b11
Message-ID: <20100205073738.9D19241EB8@hg.openjdk.java.net>

Changeset: 3913691b3021
Author:    malenkov
Date:      2010-02-05 10:36 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/3913691b3021

6921057: REGRESSION: persistence delegate issue on Windows and Linux against 5.u23b03/6u17b11
Reviewed-by: peterz, art

! src/share/classes/java/beans/Introspector.java
! test/java/beans/Introspector/6380849/TestBeanInfo.java
! test/java/beans/Introspector/Test5102804.java
! test/java/beans/XMLEncoder/Test4646747.java



From Artem.Ananiev at Sun.COM  Fri Feb  5 14:36:54 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Fri, 05 Feb 2010 17:36:54 +0300
Subject: <Swing Dev> review request for 6899434: Add affine transform
 support to JLayer
In-Reply-To: <7DA864E83CAE4D4D9EBAC77237DEF6B9@DB35TT0J>
References: <7DA864E83CAE4D4D9EBAC77237DEF6B9@DB35TT0J>
Message-ID: <4B6C2D06.7030405@sun.com>

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


From pbhome at ziggo.nl  Fri Feb  5 16:40:58 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Fri, 5 Feb 2010 17:40:58 +0100
Subject: <Swing Dev> review request for 6899434: Add affine transform
	support to JLayer
References: <7DA864E83CAE4D4D9EBAC77237DEF6B9@DB35TT0J>
	<4B6C2D06.7030405@sun.com>
Message-ID: <A597B49B47104631BB5102E7192F82FA@DB35TT0J>

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




From pbhome at ziggo.nl  Mon Feb  8 11:27:32 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Mon, 8 Feb 2010 12:27:32 +0100
Subject: <Swing Dev> Fw: review request for 6899434: Add affine
	transformsupport to JLayer
Message-ID: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>

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




From Artem.Ananiev at Sun.COM  Tue Feb  9 11:29:24 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 09 Feb 2010 14:29:24 +0300
Subject: <Swing Dev> Fw: review request for 6899434: Add
	affine	transformsupport to JLayer
In-Reply-To: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
Message-ID: <4B714714.3040108@sun.com>

Hi, Piet,

let's try to find if these two approaches could be combined together. 
What I personally like is:

1. There's no changed in Component (approach 1).

2. AWTAccessor is not changed and not used (approach 1).

3. Small changes in Container (approach 2).

As you correctly noticed, we need some (private or public) API to do 
both forward and reverse transforms - to find a component under mouse 
and to send a translated mouse event. Why couldn't we make the following 
minimal changes then:

a. Introduce a new protected method toLayoutSpace() - or whatever it's 
named - which does nothing by default, but overridden in JLayer to 
respect its transform.

b. Make findComponentAt() protected. It will then be overridden in 
JLayer to respect its inverse transform.

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

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


From pbhome at ziggo.nl  Tue Feb  9 13:30:11 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 9 Feb 2010 14:30:11 +0100
Subject: <Swing Dev> Fw: review request for 6899434: Add
	affinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
Message-ID: <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>

Hi Artem,

Thanks for the detailed evaluation.


> Hi, Piet,
>
> let's try to find if these two approaches could be combined together. What 
> I personally like is:
>
> 1. There's no changed in Component (approach 1).
>
> 2. AWTAccessor is not changed and not used (approach 1).
>
> 3. Small changes in Container (approach 2).

Ok, let's try to do it without AWTAccessor and keep the changes in Container 
as small as possible.

>
> As you correctly noticed, we need some (private or public) API to do both 
> forward and reverse transforms - to find a component under mouse and to 
> send a translated mouse event. Why couldn't we make the following minimal 
> changes then:
>
> a. Introduce a new protected method toLayoutSpace() - or whatever it's 
> named - which does nothing by default, but overridden in JLayer to respect 
> its transform.

Ok (like in approach 1). The toLayoutSpace(Point) in Container will become 
protected and will do nothing. JLayer will override it.

>
> b. Make findComponentAt() protected. It will then be overridden in JLayer 
> to respect its inverse transform.

I'm not so sure. First of all, there are two methods in Container that need 
adustment:

- findComponentAt Impl(used for lookup of a component that provides a 
cursor)
- getMouseEventTargetImpl (used for lookup of a target component for a 
MouseEvent)

Both methods use a different lookup approach and follow a chain of method 
invocations. Both are quite complicated and have some parameters that 
influence the lookup. Overriding them in JLayer would make it necessary to 
copy all that code in JLayer and just make one tiny adjustment for the 
transform.

Besides, why did we introduce the toLayoutSpace(Point) method? That method 
is intended to be used to have the Point transformed, like in version 2 
(which you liked) but without the AWTAccessor. That method is introduced 
exactly for that purpose!

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

Hmm.. I share your doubts, but nevertheless.

You forget one thing to mention: the retargeting in LightweightDispatcher 
also needs adjustment. In version 2 (which you liked) a call is made to a 
private static methods toLayoutSpace(MouseEvent) which uses the AWTAccessor.

This method can be adapted to use the Container.toLayoutSpace(Point) method 
to update the MouseEvent. The AWTAccessor pattern is then obsolete.

So, in summary,

1) The implementation in version 2 will be used but without the AWTAccessor.
:
2) Container.toLayoutSpace(Point) will become protected and the Container 
implementation does nothing.

3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private and 
static, but will be rewritten to use Container.toLayoutSpace(Point) in a 
hierachy loop.

4) LightweightDispatcher.concatenateHierarchyTransforms() will of course be 
removed.

Please let me know if you agree.

Thanks
Piet

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




From pavel.porvatov at sun.com  Wed Feb 10 12:18:01 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Wed, 10 Feb 2010 12:18:01 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6848475: JSlider does not display
	the correct	value of its BoundedRangeModel
Message-ID: <20100210121843.E549C419B7@hg.openjdk.java.net>

Changeset: e64331144648
Author:    rupashka
Date:      2010-02-10 15:15 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e64331144648

6848475: JSlider does not display the correct value of its BoundedRangeModel
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
+ test/javax/swing/JSlider/6848475/bug6848475.java



From yuka.kamiya at sun.com  Thu Feb 11 07:03:47 2010
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Thu, 11 Feb 2010 07:03:47 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6909002: Remove indicim.jar and
	thaiim.jar from	JRE and move to samples if needed
Message-ID: <20100211070405.E45E641AEB@hg.openjdk.java.net>

Changeset: f81c8041ccf4
Author:    peytoia
Date:      2010-02-11 15:58 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/f81c8041ccf4

6909002: Remove indicim.jar and thaiim.jar from JRE and move to samples if needed
Reviewed-by: okutsu

! make/com/sun/Makefile



From Anthony.Petrov at Sun.COM  Thu Feb 11 07:44:35 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Thu, 11 Feb 2010 10:44:35 +0300
Subject: <Swing Dev> <AWT Dev> Fw: review request for 6899434:
	Add	affinetransformsupport to JLayer
In-Reply-To: <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
Message-ID: <4B73B563.7080002@sun.com>

Hi Piet,

The version #2 looks very good.

On 2/9/2010 4:30 PM Piet Blok wrote:
> 1) The implementation in version 2 will be used but without the 
> AWTAccessor.

So that the Component.transform is moved over to the JLayer class, 
right? That would be great.


> 2) Container.toLayoutSpace(Point) will become protected and the 
> Container implementation does nothing.
> 
> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
> in a hierachy loop.
> 
> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
> be removed.

I like the proposal.

A minor comment regarding the code:

src/share/classes/java/awt/Container.java
> 4875         Component parent = comp.getParent();

I suggest to use the getContainer() method instead. If the comp is a 
window, the getParent() may actually return an owner of the window, 
which we certainly don't want to deal with.

Also, please make sure you format the code according the guidelines: in 
Container.java the code put in the new try{} blocks must be correctly 
indented.

Otherwise looks fine. Thanks!

--
best regards,
Anthony

> 
> Please let me know if you agree.
> 
> Thanks
> Piet
> 
>>
>> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 


From pbhome at ziggo.nl  Thu Feb 11 08:45:44 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Thu, 11 Feb 2010 09:45:44 +0100
Subject: <Swing Dev> <AWT Dev> Fw: review request for 6899434:
	Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
Message-ID: <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>

Hi Anthony,

> Hi Piet,
>
> The version #2 looks very good.

Looks, yes. Unfortunately, later I detected that it doesn't work. It's 
missing something. Oh yes, I carried out a comprehensive manual test but the 
test setup was wrong: I tested against the version 1! (A jtreg test was 
carried out against version 2 and was succesfull).

I'll try to manually add a remark to that webrev to state that it's invalid 
and should not be used.

>
> On 2/9/2010 4:30 PM Piet Blok wrote:
>> 1) The implementation in version 2 will be used but without the 
>> AWTAccessor.
>
> So that the Component.transform is moved over to the JLayer class, right? 
> That would be great.
>

Yes

>
>> 2) Container.toLayoutSpace(Point) will become protected and the Container 
>> implementation does nothing.
>>
>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
>> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
>> in a hierachy loop.
>>
>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
>> be removed.
>
> I like the proposal.

As said, something was missing: A Container.toRenderedSpace(point) is needed 
as well. This method must return the normal transformed point, as opposed to 
toLayoutSpace() that returns the inverse transformed point.

And yes, like Artem pointed out in an earlier post, this leaves the option 
open for implementers to choose for a transformation  other than 
AffineTransform. Fish eye, some sinus, whatever. (Curious to know how one 
would implement the actual rendering, but that's beside the point).

>
> A minor comment regarding the code:
>
> src/share/classes/java/awt/Container.java
>> 4875         Component parent = comp.getParent();
>
> I suggest to use the getContainer() method instead. If the comp is a 
> window, the getParent() may actually return an owner of the window, which 
> we certainly don't want to deal with.

Aha, wasn't aware of getContainer() (package private). Very good.

>
> Also, please make sure you format the code according the guidelines: in 
> Container.java the code put in the new try{} blocks must be correctly 
> indented.

This I was wondering about: should I or shouldn't I (touch code that is 
otherwise not altered). Now I know, thanks.

>
> Otherwise looks fine. Thanks!
>

Ok, I'm working on version 3. And this time actually testing against this 
same version 3!  I'm still working on some more simple jtreg test cases and 
I'll change to getContainer() and indent correctly.

Thanks,
Piet

> --
> best regards,
> Anthony
>
>>
>> Please let me know if you agree.
>>
>> Thanks
>> Piet
>>
>>>
>>> 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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From Alexander.Potochkin at Sun.COM  Thu Feb 11 12:24:26 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Thu, 11 Feb 2010 15:24:26 +0300
Subject: <Swing Dev> Fw: review request for 6899434:
	Add	affine	transformsupport to JLayer
In-Reply-To: <4B714714.3040108@sun.com>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
Message-ID: <4B73F6FA.6090602@sun.com>

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

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



From Artem.Ananiev at Sun.COM  Thu Feb 11 12:36:23 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 11 Feb 2010 15:36:23 +0300
Subject: <Swing Dev> Fw: review request for
	6899434:	Add	affine	transformsupport to JLayer
In-Reply-To: <4B73F6FA.6090602@sun.com>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <4B73F6FA.6090602@sun.com>
Message-ID: <4B73F9C7.7040802@sun.com>


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


From Alexander.Potochkin at Sun.COM  Thu Feb 11 12:45:12 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Thu, 11 Feb 2010 15:45:12 +0300
Subject: <Swing Dev> Fw: review request
	for	6899434:	Add	affine	transformsupport to JLayer
In-Reply-To: <4B73F9C7.7040802@sun.com>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <4B73F6FA.6090602@sun.com>
	<4B73F9C7.7040802@sun.com>
Message-ID: <4B73FBD8.9030302@sun.com>

Hello Artem

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

Aga, okay

It would be quite difficult to support any other transforms
then AffineTransform without having them implemented by 2D team

Anyway, I just can't wait to have this fix in JDK
:-)

Thank you guys for your time!
alexp

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



From pbhome at ziggo.nl  Thu Feb 11 14:25:29 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Thu, 11 Feb 2010 15:25:29 +0100
Subject: <Swing Dev> <AWT Dev> Fw: review request for
	6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
Message-ID: <0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>

Hi all,

Please find a third version for the webrev here: 
http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/

AWTAccessor removed again

2 protected methods for Container: toLayoutSpace(x,y) and 
toRenderedSpace(x,y), overridden in JLayer.

Use getContainer() in getRenderedSpaceShift(), but getParent() in 
getLayoutSpaceShift(). The latter because it is called from 
retargetMouseEvent which itself uses getParent() when finding the hierarchy 
translation value.

Indented the try block

Added some jtreg test cases, one a manual test.

Please review again

Thanks,
Piet





> Hi Anthony,
>
>> Hi Piet,
>>
>> The version #2 looks very good.
>
> Looks, yes. Unfortunately, later I detected that it doesn't work. It's 
> missing something. Oh yes, I carried out a comprehensive manual test but 
> the test setup was wrong: I tested against the version 1! (A jtreg test 
> was carried out against version 2 and was succesfull).
>
> I'll try to manually add a remark to that webrev to state that it's 
> invalid and should not be used.
>
>>
>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>> 1) The implementation in version 2 will be used but without the 
>>> AWTAccessor.
>>
>> So that the Component.transform is moved over to the JLayer class, right? 
>> That would be great.
>>
>
> Yes
>
>>
>>> 2) Container.toLayoutSpace(Point) will become protected and the 
>>> Container implementation does nothing.
>>>
>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain private 
>>> and static, but will be rewritten to use Container.toLayoutSpace(Point) 
>>> in a hierachy loop.
>>>
>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of course 
>>> be removed.
>>
>> I like the proposal.
>
> As said, something was missing: A Container.toRenderedSpace(point) is 
> needed as well. This method must return the normal transformed point, as 
> opposed to toLayoutSpace() that returns the inverse transformed point.
>
> And yes, like Artem pointed out in an earlier post, this leaves the option 
> open for implementers to choose for a transformation  other than 
> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how one 
> would implement the actual rendering, but that's beside the point).
>
>>
>> A minor comment regarding the code:
>>
>> src/share/classes/java/awt/Container.java
>>> 4875         Component parent = comp.getParent();
>>
>> I suggest to use the getContainer() method instead. If the comp is a 
>> window, the getParent() may actually return an owner of the window, which 
>> we certainly don't want to deal with.
>
> Aha, wasn't aware of getContainer() (package private). Very good.
>
>>
>> Also, please make sure you format the code according the guidelines: in 
>> Container.java the code put in the new try{} blocks must be correctly 
>> indented.
>
> This I was wondering about: should I or shouldn't I (touch code that is 
> otherwise not altered). Now I know, thanks.
>
>>
>> Otherwise looks fine. Thanks!
>>
>
> Ok, I'm working on version 3. And this time actually testing against this 
> same version 3!  I'm still working on some more simple jtreg test cases 
> and I'll change to getContainer() and indent correctly.
>
> Thanks,
> Piet
>
>> --
>> best regards,
>> Anthony
>>
>>>
>>> Please let me know if you agree.
>>>
>>> Thanks
>>> Piet
>>>
>>>>
>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
> 




From Artem.Ananiev at Sun.COM  Thu Feb 11 17:48:03 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Thu, 11 Feb 2010 20:48:03 +0300
Subject: <Swing Dev> <AWT Dev> Fw: review request
	for	6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
Message-ID: <4B7442D3.3040709@sun.com>

Hi, Piet,

the 3rd version looks really great! I haven't looked to Swing code much, 
though :)

A small suggestion is to unify getRenderedSpaceShift() and 
getLayoutSpaceShift(), so they both accept a Component and a Point to 
translate. Could they also be static methods? It seems not, as I see a 
reference to "nativeContainer" in getLayoutSpaceShift()...

Thanks,

Artem

On 2/11/2010 5:25 PM, Piet Blok wrote:
> Hi all,
>
> Please find a third version for the webrev here:
> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>
> AWTAccessor removed again
>
> 2 protected methods for Container: toLayoutSpace(x,y) and
> toRenderedSpace(x,y), overridden in JLayer.
>
> Use getContainer() in getRenderedSpaceShift(), but getParent() in
> getLayoutSpaceShift(). The latter because it is called from
> retargetMouseEvent which itself uses getParent() when finding the
> hierarchy translation value.
>
> Indented the try block
>
> Added some jtreg test cases, one a manual test.
>
> Please review again
>
> Thanks,
> Piet
>
>
>
>
>
>> Hi Anthony,
>>
>>> Hi Piet,
>>>
>>> The version #2 looks very good.
>>
>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>> missing something. Oh yes, I carried out a comprehensive manual test
>> but the test setup was wrong: I tested against the version 1! (A jtreg
>> test was carried out against version 2 and was succesfull).
>>
>> I'll try to manually add a remark to that webrev to state that it's
>> invalid and should not be used.
>>
>>>
>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>> 1) The implementation in version 2 will be used but without the
>>>> AWTAccessor.
>>>
>>> So that the Component.transform is moved over to the JLayer class,
>>> right? That would be great.
>>>
>>
>> Yes
>>
>>>
>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>> Container implementation does nothing.
>>>>
>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>> private and static, but will be rewritten to use
>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>
>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>> course be removed.
>>>
>>> I like the proposal.
>>
>> As said, something was missing: A Container.toRenderedSpace(point) is
>> needed as well. This method must return the normal transformed point,
>> as opposed to toLayoutSpace() that returns the inverse transformed point.
>>
>> And yes, like Artem pointed out in an earlier post, this leaves the
>> option open for implementers to choose for a transformation other than
>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>> one would implement the actual rendering, but that's beside the point).
>>
>>>
>>> A minor comment regarding the code:
>>>
>>> src/share/classes/java/awt/Container.java
>>>> 4875 Component parent = comp.getParent();
>>>
>>> I suggest to use the getContainer() method instead. If the comp is a
>>> window, the getParent() may actually return an owner of the window,
>>> which we certainly don't want to deal with.
>>
>> Aha, wasn't aware of getContainer() (package private). Very good.
>>
>>>
>>> Also, please make sure you format the code according the guidelines:
>>> in Container.java the code put in the new try{} blocks must be
>>> correctly indented.
>>
>> This I was wondering about: should I or shouldn't I (touch code that
>> is otherwise not altered). Now I know, thanks.
>>
>>>
>>> Otherwise looks fine. Thanks!
>>>
>>
>> Ok, I'm working on version 3. And this time actually testing against
>> this same version 3! I'm still working on some more simple jtreg test
>> cases and I'll change to getContainer() and indent correctly.
>>
>> Thanks,
>> Piet
>>
>>> --
>>> best regards,
>>> Anthony
>>>
>>>>
>>>> Please let me know if you agree.
>>>>
>>>> Thanks
>>>> Piet
>>>>
>>>>>
>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>


From yuka.kamiya at sun.com  Fri Feb 12 05:46:13 2010
From: yuka.kamiya at sun.com (yuka.kamiya at sun.com)
Date: Fri, 12 Feb 2010 05:46:13 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6921289: (tz) Support tzdata2010b
Message-ID: <20100212054632.EE31041C63@hg.openjdk.java.net>

Changeset: e2b58a45a426
Author:    peytoia
Date:      2010-02-12 14:38 +0900
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e2b58a45a426

6921289: (tz) Support tzdata2010b
Reviewed-by: okutsu

! make/sun/javazic/tzdata/VERSION
! make/sun/javazic/tzdata/antarctica
! make/sun/javazic/tzdata/asia
! make/sun/javazic/tzdata/australasia
! make/sun/javazic/tzdata/europe
! make/sun/javazic/tzdata/northamerica
! make/sun/javazic/tzdata/zone.tab
! src/share/classes/sun/util/resources/TimeZoneNames.java
! src/share/classes/sun/util/resources/TimeZoneNames_de.java
! src/share/classes/sun/util/resources/TimeZoneNames_es.java
! src/share/classes/sun/util/resources/TimeZoneNames_fr.java
! src/share/classes/sun/util/resources/TimeZoneNames_it.java
! src/share/classes/sun/util/resources/TimeZoneNames_ja.java
! src/share/classes/sun/util/resources/TimeZoneNames_ko.java
! src/share/classes/sun/util/resources/TimeZoneNames_sv.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_CN.java
! src/share/classes/sun/util/resources/TimeZoneNames_zh_TW.java



From pbhome at ziggo.nl  Fri Feb 12 07:53:38 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Fri, 12 Feb 2010 08:53:38 +0100
Subject: <Swing Dev> <AWT Dev> Fw: review request
	for6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
Message-ID: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>


Hi Artem,

The webrev for version 3.1: 
http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/


> Hi, Piet,
>
> the 3rd version looks really great! I haven't looked to Swing code much, 
> though :)
>
> A small suggestion is to unify getRenderedSpaceShift() and 
> getLayoutSpaceShift(), so they both accept a Component and a Point to 
> translate. Could they also be static methods? It seems not, as I see a 
> reference to "nativeContainer" in getLayoutSpaceShift()...

I unified both methods and made them static after adding nativeContainer as 
a parameter to both. Their signature is now:

private static Point getXXXSpaceShift(Component target, Point dstPoint, 
Container nativeContainer)

(the nativeContainer argument is used in only one of the methods)

For the swing guys: in SwingUtilities and RepaintManager, where iterating 
over the parent hierarchy, I added a check to "parent != null" to also check 
"!(parent instanceof Window)".

Thanks,
Piet

>
> Thanks,
>
> Artem
>
> On 2/11/2010 5:25 PM, Piet Blok wrote:
>> Hi all,
>>
>> Please find a third version for the webrev here:
>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>
>> AWTAccessor removed again
>>
>> 2 protected methods for Container: toLayoutSpace(x,y) and
>> toRenderedSpace(x,y), overridden in JLayer.
>>
>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>> getLayoutSpaceShift(). The latter because it is called from
>> retargetMouseEvent which itself uses getParent() when finding the
>> hierarchy translation value.
>>
>> Indented the try block
>>
>> Added some jtreg test cases, one a manual test.
>>
>> Please review again
>>
>> Thanks,
>> Piet
>>
>>
>>
>>
>>
>>> Hi Anthony,
>>>
>>>> Hi Piet,
>>>>
>>>> The version #2 looks very good.
>>>
>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>> missing something. Oh yes, I carried out a comprehensive manual test
>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>> test was carried out against version 2 and was succesfull).
>>>
>>> I'll try to manually add a remark to that webrev to state that it's
>>> invalid and should not be used.
>>>
>>>>
>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>> 1) The implementation in version 2 will be used but without the
>>>>> AWTAccessor.
>>>>
>>>> So that the Component.transform is moved over to the JLayer class,
>>>> right? That would be great.
>>>>
>>>
>>> Yes
>>>
>>>>
>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>> Container implementation does nothing.
>>>>>
>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>> private and static, but will be rewritten to use
>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>
>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>> course be removed.
>>>>
>>>> I like the proposal.
>>>
>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>> needed as well. This method must return the normal transformed point,
>>> as opposed to toLayoutSpace() that returns the inverse transformed 
>>> point.
>>>
>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>> option open for implementers to choose for a transformation other than
>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>> one would implement the actual rendering, but that's beside the point).
>>>
>>>>
>>>> A minor comment regarding the code:
>>>>
>>>> src/share/classes/java/awt/Container.java
>>>>> 4875 Component parent = comp.getParent();
>>>>
>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>> window, the getParent() may actually return an owner of the window,
>>>> which we certainly don't want to deal with.
>>>
>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>
>>>>
>>>> Also, please make sure you format the code according the guidelines:
>>>> in Container.java the code put in the new try{} blocks must be
>>>> correctly indented.
>>>
>>> This I was wondering about: should I or shouldn't I (touch code that
>>> is otherwise not altered). Now I know, thanks.
>>>
>>>>
>>>> Otherwise looks fine. Thanks!
>>>>
>>>
>>> Ok, I'm working on version 3. And this time actually testing against
>>> this same version 3! I'm still working on some more simple jtreg test
>>> cases and I'll change to getContainer() and indent correctly.
>>>
>>> Thanks,
>>> Piet
>>>
>>>> --
>>>> best regards,
>>>> Anthony
>>>>
>>>>>
>>>>> Please let me know if you agree.
>>>>>
>>>>> Thanks
>>>>> Piet
>>>>>
>>>>>>
>>>>>> 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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>
>>
> 




From Alexander.Potochkin at Sun.COM  Fri Feb 12 14:52:38 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Fri, 12 Feb 2010 17:52:38 +0300
Subject: <Swing Dev> <AWT Dev> Fw: review
	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
Message-ID: <4B756B36.8030802@sun.com>

Hello Piet

I am fine with 3rd version,
waiting for the comments from AWT guys

Thanks!
alexp

>
> Hi Artem,
>
> The webrev for version 3.1:
> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>
>
>> Hi, Piet,
>>
>> the 3rd version looks really great! I haven't looked to Swing code
>> much, though :)
>>
>> A small suggestion is to unify getRenderedSpaceShift() and
>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>> translate. Could they also be static methods? It seems not, as I see a
>> reference to "nativeContainer" in getLayoutSpaceShift()...
>
> I unified both methods and made them static after adding nativeContainer
> as a parameter to both. Their signature is now:
>
> private static Point getXXXSpaceShift(Component target, Point dstPoint,
> Container nativeContainer)
>
> (the nativeContainer argument is used in only one of the methods)
>
> For the swing guys: in SwingUtilities and RepaintManager, where
> iterating over the parent hierarchy, I added a check to "parent != null"
> to also check "!(parent instanceof Window)".
>
> Thanks,
> Piet
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>> Hi all,
>>>
>>> Please find a third version for the webrev here:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>
>>> AWTAccessor removed again
>>>
>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>> toRenderedSpace(x,y), overridden in JLayer.
>>>
>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>> getLayoutSpaceShift(). The latter because it is called from
>>> retargetMouseEvent which itself uses getParent() when finding the
>>> hierarchy translation value.
>>>
>>> Indented the try block
>>>
>>> Added some jtreg test cases, one a manual test.
>>>
>>> Please review again
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>>
>>>
>>>> Hi Anthony,
>>>>
>>>>> Hi Piet,
>>>>>
>>>>> The version #2 looks very good.
>>>>
>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>> test was carried out against version 2 and was succesfull).
>>>>
>>>> I'll try to manually add a remark to that webrev to state that it's
>>>> invalid and should not be used.
>>>>
>>>>>
>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>> AWTAccessor.
>>>>>
>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>> right? That would be great.
>>>>>
>>>>
>>>> Yes
>>>>
>>>>>
>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>> Container implementation does nothing.
>>>>>>
>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>> private and static, but will be rewritten to use
>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>
>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>> course be removed.
>>>>>
>>>>> I like the proposal.
>>>>
>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>> needed as well. This method must return the normal transformed point,
>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>> point.
>>>>
>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>> option open for implementers to choose for a transformation other than
>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>> one would implement the actual rendering, but that's beside the point).
>>>>
>>>>>
>>>>> A minor comment regarding the code:
>>>>>
>>>>> src/share/classes/java/awt/Container.java
>>>>>> 4875 Component parent = comp.getParent();
>>>>>
>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>> window, the getParent() may actually return an owner of the window,
>>>>> which we certainly don't want to deal with.
>>>>
>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>
>>>>>
>>>>> Also, please make sure you format the code according the guidelines:
>>>>> in Container.java the code put in the new try{} blocks must be
>>>>> correctly indented.
>>>>
>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>> is otherwise not altered). Now I know, thanks.
>>>>
>>>>>
>>>>> Otherwise looks fine. Thanks!
>>>>>
>>>>
>>>> Ok, I'm working on version 3. And this time actually testing against
>>>> this same version 3! I'm still working on some more simple jtreg test
>>>> cases and I'll change to getContainer() and indent correctly.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Please let me know if you agree.
>>>>>>
>>>>>> Thanks
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>



From Alexander.Potochkin at Sun.COM  Fri Feb 12 14:56:21 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Fri, 12 Feb 2010 17:56:21 +0300
Subject: <Swing Dev> <AWT Dev> Fw:
	review	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <4B756B36.8030802@sun.com>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B756B36.8030802@sun.com>
Message-ID: <4B756C15.5020502@sun.com>


> Hello Piet
>
> I am fine with 3rd version,
> waiting for the comments from AWT guys

small correction:

I meant 3.1 version (the latest one)

Thanks again
alexp

>
> Thanks!
> alexp
>
>>
>> Hi Artem,
>>
>> The webrev for version 3.1:
>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>
>>
>>> Hi, Piet,
>>>
>>> the 3rd version looks really great! I haven't looked to Swing code
>>> much, though :)
>>>
>>> A small suggestion is to unify getRenderedSpaceShift() and
>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>> translate. Could they also be static methods? It seems not, as I see a
>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>
>> I unified both methods and made them static after adding nativeContainer
>> as a parameter to both. Their signature is now:
>>
>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>> Container nativeContainer)
>>
>> (the nativeContainer argument is used in only one of the methods)
>>
>> For the swing guys: in SwingUtilities and RepaintManager, where
>> iterating over the parent hierarchy, I added a check to "parent != null"
>> to also check "!(parent instanceof Window)".
>>
>> Thanks,
>> Piet
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>> Hi all,
>>>>
>>>> Please find a third version for the webrev here:
>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>
>>>> AWTAccessor removed again
>>>>
>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>
>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>> getLayoutSpaceShift(). The latter because it is called from
>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>> hierarchy translation value.
>>>>
>>>> Indented the try block
>>>>
>>>> Added some jtreg test cases, one a manual test.
>>>>
>>>> Please review again
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Anthony,
>>>>>
>>>>>> Hi Piet,
>>>>>>
>>>>>> The version #2 looks very good.
>>>>>
>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>>> test was carried out against version 2 and was succesfull).
>>>>>
>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>> invalid and should not be used.
>>>>>
>>>>>>
>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>> AWTAccessor.
>>>>>>
>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>> right? That would be great.
>>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>> Container implementation does nothing.
>>>>>>>
>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>> private and static, but will be rewritten to use
>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>
>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>> course be removed.
>>>>>>
>>>>>> I like the proposal.
>>>>>
>>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>>> needed as well. This method must return the normal transformed point,
>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>> point.
>>>>>
>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>> option open for implementers to choose for a transformation other than
>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>>> one would implement the actual rendering, but that's beside the
>>>>> point).
>>>>>
>>>>>>
>>>>>> A minor comment regarding the code:
>>>>>>
>>>>>> src/share/classes/java/awt/Container.java
>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>
>>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>> which we certainly don't want to deal with.
>>>>>
>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>
>>>>>>
>>>>>> Also, please make sure you format the code according the guidelines:
>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>> correctly indented.
>>>>>
>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>> is otherwise not altered). Now I know, thanks.
>>>>>
>>>>>>
>>>>>> Otherwise looks fine. Thanks!
>>>>>>
>>>>>
>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>> this same version 3! I'm still working on some more simple jtreg test
>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>>>
>>>>>>> Please let me know if you agree.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Piet
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>



From Anthony.Petrov at Sun.COM  Fri Feb 12 17:06:08 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Fri, 12 Feb 2010 20:06:08 +0300
Subject: <Swing Dev> <AWT Dev> Fw: review
	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
Message-ID: <4B758A80.3070101@sun.com>

Hi Piet,

The fix looks fine. Thanks.

--
best regards,
Anthony


On 02/12/2010 10:53 AM, Piet Blok wrote:
> 
> Hi Artem,
> 
> The webrev for version 3.1: 
> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
> 
> 
>> Hi, Piet,
>>
>> the 3rd version looks really great! I haven't looked to Swing code 
>> much, though :)
>>
>> A small suggestion is to unify getRenderedSpaceShift() and 
>> getLayoutSpaceShift(), so they both accept a Component and a Point to 
>> translate. Could they also be static methods? It seems not, as I see a 
>> reference to "nativeContainer" in getLayoutSpaceShift()...
> 
> I unified both methods and made them static after adding nativeContainer 
> as a parameter to both. Their signature is now:
> 
> private static Point getXXXSpaceShift(Component target, Point dstPoint, 
> Container nativeContainer)
> 
> (the nativeContainer argument is used in only one of the methods)
> 
> For the swing guys: in SwingUtilities and RepaintManager, where 
> iterating over the parent hierarchy, I added a check to "parent != null" 
> to also check "!(parent instanceof Window)".
> 
> Thanks,
> Piet
> 
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>> Hi all,
>>>
>>> Please find a third version for the webrev here:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>
>>> AWTAccessor removed again
>>>
>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>> toRenderedSpace(x,y), overridden in JLayer.
>>>
>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>> getLayoutSpaceShift(). The latter because it is called from
>>> retargetMouseEvent which itself uses getParent() when finding the
>>> hierarchy translation value.
>>>
>>> Indented the try block
>>>
>>> Added some jtreg test cases, one a manual test.
>>>
>>> Please review again
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>>
>>>
>>>> Hi Anthony,
>>>>
>>>>> Hi Piet,
>>>>>
>>>>> The version #2 looks very good.
>>>>
>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>> test was carried out against version 2 and was succesfull).
>>>>
>>>> I'll try to manually add a remark to that webrev to state that it's
>>>> invalid and should not be used.
>>>>
>>>>>
>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>> AWTAccessor.
>>>>>
>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>> right? That would be great.
>>>>>
>>>>
>>>> Yes
>>>>
>>>>>
>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>> Container implementation does nothing.
>>>>>>
>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>> private and static, but will be rewritten to use
>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>
>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>> course be removed.
>>>>>
>>>>> I like the proposal.
>>>>
>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>> needed as well. This method must return the normal transformed point,
>>>> as opposed to toLayoutSpace() that returns the inverse transformed 
>>>> point.
>>>>
>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>> option open for implementers to choose for a transformation other than
>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>> one would implement the actual rendering, but that's beside the point).
>>>>
>>>>>
>>>>> A minor comment regarding the code:
>>>>>
>>>>> src/share/classes/java/awt/Container.java
>>>>>> 4875 Component parent = comp.getParent();
>>>>>
>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>> window, the getParent() may actually return an owner of the window,
>>>>> which we certainly don't want to deal with.
>>>>
>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>
>>>>>
>>>>> Also, please make sure you format the code according the guidelines:
>>>>> in Container.java the code put in the new try{} blocks must be
>>>>> correctly indented.
>>>>
>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>> is otherwise not altered). Now I know, thanks.
>>>>
>>>>>
>>>>> Otherwise looks fine. Thanks!
>>>>>
>>>>
>>>> Ok, I'm working on version 3. And this time actually testing against
>>>> this same version 3! I'm still working on some more simple jtreg test
>>>> cases and I'll change to getContainer() and indent correctly.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>> -- 
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Please let me know if you agree.
>>>>>>
>>>>>> Thanks
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 


From Artem.Ananiev at Sun.COM  Tue Feb 16 12:49:46 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Feb 2010 15:49:46 +0300
Subject: <Swing Dev> <AWT Dev> Fw: review
	request	for6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
Message-ID: <4B7A946A.6000503@sun.com>

Hi, Piet,

the fix looks pretty good in general. Some small comments:

1. As we're about to introduce 2 new public methods into Container, we 
need to provide a description of "layout space" and "render space". I 
hope you or Alex will take care of this.

2. Could toRenderedSpace() throw NoninvertibleTransformException as well?

3. getRenderedSpaceShift() - should we traverse containers up to null or 
up to the nativeContainer?

Thanks,

Artem

On 2/12/2010 10:53 AM, Piet Blok wrote:
>
> Hi Artem,
>
> The webrev for version 3.1:
> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>
>
>> Hi, Piet,
>>
>> the 3rd version looks really great! I haven't looked to Swing code
>> much, though :)
>>
>> A small suggestion is to unify getRenderedSpaceShift() and
>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>> translate. Could they also be static methods? It seems not, as I see a
>> reference to "nativeContainer" in getLayoutSpaceShift()...
>
> I unified both methods and made them static after adding nativeContainer
> as a parameter to both. Their signature is now:
>
> private static Point getXXXSpaceShift(Component target, Point dstPoint,
> Container nativeContainer)
>
> (the nativeContainer argument is used in only one of the methods)
>
> For the swing guys: in SwingUtilities and RepaintManager, where
> iterating over the parent hierarchy, I added a check to "parent != null"
> to also check "!(parent instanceof Window)".
>
> Thanks,
> Piet
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>> Hi all,
>>>
>>> Please find a third version for the webrev here:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>
>>> AWTAccessor removed again
>>>
>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>> toRenderedSpace(x,y), overridden in JLayer.
>>>
>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>> getLayoutSpaceShift(). The latter because it is called from
>>> retargetMouseEvent which itself uses getParent() when finding the
>>> hierarchy translation value.
>>>
>>> Indented the try block
>>>
>>> Added some jtreg test cases, one a manual test.
>>>
>>> Please review again
>>>
>>> Thanks,
>>> Piet
>>>
>>>
>>>
>>>
>>>
>>>> Hi Anthony,
>>>>
>>>>> Hi Piet,
>>>>>
>>>>> The version #2 looks very good.
>>>>
>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>> test was carried out against version 2 and was succesfull).
>>>>
>>>> I'll try to manually add a remark to that webrev to state that it's
>>>> invalid and should not be used.
>>>>
>>>>>
>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>> AWTAccessor.
>>>>>
>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>> right? That would be great.
>>>>>
>>>>
>>>> Yes
>>>>
>>>>>
>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>> Container implementation does nothing.
>>>>>>
>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>> private and static, but will be rewritten to use
>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>
>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>> course be removed.
>>>>>
>>>>> I like the proposal.
>>>>
>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>> needed as well. This method must return the normal transformed point,
>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>> point.
>>>>
>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>> option open for implementers to choose for a transformation other than
>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>> one would implement the actual rendering, but that's beside the point).
>>>>
>>>>>
>>>>> A minor comment regarding the code:
>>>>>
>>>>> src/share/classes/java/awt/Container.java
>>>>>> 4875 Component parent = comp.getParent();
>>>>>
>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>> window, the getParent() may actually return an owner of the window,
>>>>> which we certainly don't want to deal with.
>>>>
>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>
>>>>>
>>>>> Also, please make sure you format the code according the guidelines:
>>>>> in Container.java the code put in the new try{} blocks must be
>>>>> correctly indented.
>>>>
>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>> is otherwise not altered). Now I know, thanks.
>>>>
>>>>>
>>>>> Otherwise looks fine. Thanks!
>>>>>
>>>>
>>>> Ok, I'm working on version 3. And this time actually testing against
>>>> this same version 3! I'm still working on some more simple jtreg test
>>>> cases and I'll change to getContainer() and indent correctly.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>> --
>>>>> best regards,
>>>>> Anthony
>>>>>
>>>>>>
>>>>>> Please let me know if you agree.
>>>>>>
>>>>>> Thanks
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>
>


From pbhome at ziggo.nl  Tue Feb 16 15:12:13 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 16 Feb 2010 16:12:13 +0100
Subject: <Swing Dev> <AWT Dev> Fw: review
	requestfor6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
Message-ID: <1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>

Hi Artem

> Hi, Piet,
>
> the fix looks pretty good in general. Some small comments:
>
> 1. As we're about to introduce 2 new public methods into Container, we 
> need to provide a description of "layout space" and "render space". I hope 
> you or Alex will take care of this.

What about the following descriptions?

Layout space refers to user space (coordinates in the layout system).
Rendered space refers to device space (coordinates on the screen).
Please see (link to) AffineTransform.

>
> 2. Could toRenderedSpace() throw NoninvertibleTransformException as well?

No. toRenderedSpace() is a direct transformation with any of 
AffineTransform's transform() methods.
This in contrast to inverse operations as used in toLayoutSpace(), like 
AffineTransform's createInverse() and inverseTransform() methods that may 
throw this exception.

>
> 3. getRenderedSpaceShift() - should we traverse containers up to null or 
> up to the nativeContainer?

Good point. For testing I added a test "not nativeContainer" to the null 
test and everything still works (in my own test suite that is far more 
complex than the provided jtreg test cases).

getRenderedSpaceShift() is invoked from eventDispatched. It should do a 
traversal that is analogous to the traversal there.

In general, I'm not sure about the role of "nativeContainer" and how it is 
used. For example, I don't know if (one or more)  native containers can be 
present in the hierachy between a Window and the lowest child component. Or 
is the top Window always the native container? If this is not the case, 
could you depict some hierarchy example where a native container is a child 
somewhere in the hierarchy of a JLayer's view? Then I can do a more 
comprehensive test.

Please let me know, so I can prepare a version 3.2  if needed (and add the 
descriptions at the same time)

Thanks,
Piet.

>
> Thanks,
>
> Artem
>
> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>
>> Hi Artem,
>>
>> The webrev for version 3.1:
>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>
>>
>>> Hi, Piet,
>>>
>>> the 3rd version looks really great! I haven't looked to Swing code
>>> much, though :)
>>>
>>> A small suggestion is to unify getRenderedSpaceShift() and
>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>> translate. Could they also be static methods? It seems not, as I see a
>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>
>> I unified both methods and made them static after adding nativeContainer
>> as a parameter to both. Their signature is now:
>>
>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>> Container nativeContainer)
>>
>> (the nativeContainer argument is used in only one of the methods)
>>
>> For the swing guys: in SwingUtilities and RepaintManager, where
>> iterating over the parent hierarchy, I added a check to "parent != null"
>> to also check "!(parent instanceof Window)".
>>
>> Thanks,
>> Piet
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>> Hi all,
>>>>
>>>> Please find a third version for the webrev here:
>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>
>>>> AWTAccessor removed again
>>>>
>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>
>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>> getLayoutSpaceShift(). The latter because it is called from
>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>> hierarchy translation value.
>>>>
>>>> Indented the try block
>>>>
>>>> Added some jtreg test cases, one a manual test.
>>>>
>>>> Please review again
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> Hi Anthony,
>>>>>
>>>>>> Hi Piet,
>>>>>>
>>>>>> The version #2 looks very good.
>>>>>
>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work. It's
>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>> but the test setup was wrong: I tested against the version 1! (A jtreg
>>>>> test was carried out against version 2 and was succesfull).
>>>>>
>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>> invalid and should not be used.
>>>>>
>>>>>>
>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>> AWTAccessor.
>>>>>>
>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>> right? That would be great.
>>>>>>
>>>>>
>>>>> Yes
>>>>>
>>>>>>
>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>> Container implementation does nothing.
>>>>>>>
>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>> private and static, but will be rewritten to use
>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>
>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>> course be removed.
>>>>>>
>>>>>> I like the proposal.
>>>>>
>>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>>> needed as well. This method must return the normal transformed point,
>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>> point.
>>>>>
>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>> option open for implementers to choose for a transformation other than
>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>>> one would implement the actual rendering, but that's beside the 
>>>>> point).
>>>>>
>>>>>>
>>>>>> A minor comment regarding the code:
>>>>>>
>>>>>> src/share/classes/java/awt/Container.java
>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>
>>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>> which we certainly don't want to deal with.
>>>>>
>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>
>>>>>>
>>>>>> Also, please make sure you format the code according the guidelines:
>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>> correctly indented.
>>>>>
>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>> is otherwise not altered). Now I know, thanks.
>>>>>
>>>>>>
>>>>>> Otherwise looks fine. Thanks!
>>>>>>
>>>>>
>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>> this same version 3! I'm still working on some more simple jtreg test
>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>> --
>>>>>> best regards,
>>>>>> Anthony
>>>>>>
>>>>>>>
>>>>>>> Please let me know if you agree.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Piet
>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From Artem.Ananiev at Sun.COM  Tue Feb 16 15:54:21 2010
From: Artem.Ananiev at Sun.COM (Artem Ananiev)
Date: Tue, 16 Feb 2010 18:54:21 +0300
Subject: <Swing Dev> <AWT Dev> Fw:
	review	requestfor6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
Message-ID: <4B7ABFAD.8060403@sun.com>


On 2/16/2010 6:12 PM, Piet Blok wrote:
> Hi Artem
>
>> Hi, Piet,
>>
>> the fix looks pretty good in general. Some small comments:
>>
>> 1. As we're about to introduce 2 new public methods into Container, we
>> need to provide a description of "layout space" and "render space". I
>> hope you or Alex will take care of this.
>
> What about the following descriptions?
>
> Layout space refers to user space (coordinates in the layout system).
> Rendered space refers to device space (coordinates on the screen).
> Please see (link to) AffineTransform.

Probably, we should mention that layout coordinates are the ones used by 
LayoutManager and other Container stuff. For example, 
Component.getBounds() always returns layout rectangle, not rendered one.

>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as well?
>
> No. toRenderedSpace() is a direct transformation with any of
> AffineTransform's transform() methods.
> This in contrast to inverse operations as used in toLayoutSpace(), like
> AffineTransform's createInverse() and inverseTransform() methods that
> may throw this exception.

It depends on what we consider a forward transform and a reverse 
transform :) And don't forget there may be non-affine transforms...

>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>> or up to the nativeContainer?
>
> Good point. For testing I added a test "not nativeContainer" to the null
> test and everything still works (in my own test suite that is far more
> complex than the provided jtreg test cases).
>
> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
> traversal that is analogous to the traversal there.
>
> In general, I'm not sure about the role of "nativeContainer" and how it
> is used. For example, I don't know if (one or more) native containers
> can be present in the hierachy between a Window and the lowest child
> component. Or is the top Window always the native container? If this is
> not the case, could you depict some hierarchy example where a native
> container is a child somewhere in the hierarchy of a JLayer's view? Then
> I can do a more comprehensive test.

nativeContainer is a basic part of LightweightDispatcher machinery: it 
is the container, always heavyweight, which is served by the dispatcher. 
An obvious example is how all the mouse events are dispatched: we (AWT) 
receive events for heavyweight components only as the underlying OS 
isn't aware of our lightweight Swing components. When the event is 
dispatched to a heavyweight container, it's lightweight dispatcher 
retargets it to a proper lightweight child.

Given that we won't support transformations for heavyweight components 
(BTW, it should also be reflected in JavaDoc), it's enough to care about 
nativeContainer children only.

> Please let me know, so I can prepare a version 3.2 if needed (and add
> the descriptions at the same time)

3.2 is only required if you make any significant changes based on the 
current discussion.

Thanks,

Artem

> Thanks,
> Piet.
>
>>
>> Thanks,
>>
>> Artem
>>
>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>
>>> Hi Artem,
>>>
>>> The webrev for version 3.1:
>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>
>>>
>>>> Hi, Piet,
>>>>
>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>> much, though :)
>>>>
>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>> translate. Could they also be static methods? It seems not, as I see a
>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>
>>> I unified both methods and made them static after adding nativeContainer
>>> as a parameter to both. Their signature is now:
>>>
>>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>>> Container nativeContainer)
>>>
>>> (the nativeContainer argument is used in only one of the methods)
>>>
>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>> iterating over the parent hierarchy, I added a check to "parent != null"
>>> to also check "!(parent instanceof Window)".
>>>
>>> Thanks,
>>> Piet
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>> Hi all,
>>>>>
>>>>> Please find a third version for the webrev here:
>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>
>>>>> AWTAccessor removed again
>>>>>
>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>
>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>> hierarchy translation value.
>>>>>
>>>>> Indented the try block
>>>>>
>>>>> Added some jtreg test cases, one a manual test.
>>>>>
>>>>> Please review again
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hi Anthony,
>>>>>>
>>>>>>> Hi Piet,
>>>>>>>
>>>>>>> The version #2 looks very good.
>>>>>>
>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>> It's
>>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>> jtreg
>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>
>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>> invalid and should not be used.
>>>>>>
>>>>>>>
>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>> AWTAccessor.
>>>>>>>
>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>> right? That would be great.
>>>>>>>
>>>>>>
>>>>>> Yes
>>>>>>
>>>>>>>
>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>> Container implementation does nothing.
>>>>>>>>
>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>> private and static, but will be rewritten to use
>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>
>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>> course be removed.
>>>>>>>
>>>>>>> I like the proposal.
>>>>>>
>>>>>> As said, something was missing: A Container.toRenderedSpace(point) is
>>>>>> needed as well. This method must return the normal transformed point,
>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>> point.
>>>>>>
>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>> option open for implementers to choose for a transformation other
>>>>>> than
>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know how
>>>>>> one would implement the actual rendering, but that's beside the
>>>>>> point).
>>>>>>
>>>>>>>
>>>>>>> A minor comment regarding the code:
>>>>>>>
>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>
>>>>>>> I suggest to use the getContainer() method instead. If the comp is a
>>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>>> which we certainly don't want to deal with.
>>>>>>
>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>
>>>>>>>
>>>>>>> Also, please make sure you format the code according the guidelines:
>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>> correctly indented.
>>>>>>
>>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>
>>>>>>>
>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>
>>>>>>
>>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>>> this same version 3! I'm still working on some more simple jtreg test
>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>> --
>>>>>>> best regards,
>>>>>>> Anthony
>>>>>>>
>>>>>>>>
>>>>>>>> Please let me know if you agree.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From pbhome at ziggo.nl  Tue Feb 16 16:34:35 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Tue, 16 Feb 2010 17:34:35 +0100
Subject: <Swing Dev> <AWT Dev> Fw:
	reviewrequestfor6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
	<4B7ABFAD.8060403@sun.com>
Message-ID: <53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>


Hi Artem


>
> On 2/16/2010 6:12 PM, Piet Blok wrote:
>> Hi Artem
>>
>>> Hi, Piet,
>>>
>>> the fix looks pretty good in general. Some small comments:
>>>
>>> 1. As we're about to introduce 2 new public methods into Container, we
>>> need to provide a description of "layout space" and "render space". I
>>> hope you or Alex will take care of this.
>>
>> What about the following descriptions?
>>
>> Layout space refers to user space (coordinates in the layout system).
>> Rendered space refers to device space (coordinates on the screen).
>> Please see (link to) AffineTransform.
>
> Probably, we should mention that layout coordinates are the ones used by 
> LayoutManager and other Container stuff. For example, 
> Component.getBounds() always returns layout rectangle, not rendered one.

Ok, good addition. I'll add that clarification.

>
>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as 
>>> well?
>>
>> No. toRenderedSpace() is a direct transformation with any of
>> AffineTransform's transform() methods.
>> This in contrast to inverse operations as used in toLayoutSpace(), like
>> AffineTransform's createInverse() and inverseTransform() methods that
>> may throw this exception.
>
> It depends on what we consider a forward transform and a reverse transform 
> :) And don't forget there may be non-affine transforms...

Any transform, be it affine or non-affine is able by definition to 
transform, otherwise it's not a transform :-)

Only inverse transform can be problematic. That is, when two different 
points, after transformation, result in the same point. Valid during 
transform. But impossible to do an inverse. Analogous to multiplying by zero 
is valid, but the operation can't be inversed.

>
>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>> or up to the nativeContainer?
>>
>> Good point. For testing I added a test "not nativeContainer" to the null
>> test and everything still works (in my own test suite that is far more
>> complex than the provided jtreg test cases).
>>
>> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
>> traversal that is analogous to the traversal there.
>>
>> In general, I'm not sure about the role of "nativeContainer" and how it
>> is used. For example, I don't know if (one or more) native containers
>> can be present in the hierachy between a Window and the lowest child
>> component. Or is the top Window always the native container? If this is
>> not the case, could you depict some hierarchy example where a native
>> container is a child somewhere in the hierarchy of a JLayer's view? Then
>> I can do a more comprehensive test.
>
> nativeContainer is a basic part of LightweightDispatcher machinery: it is 
> the container, always heavyweight, which is served by the dispatcher. An 
> obvious example is how all the mouse events are dispatched: we (AWT) 
> receive events for heavyweight components only as the underlying OS isn't 
> aware of our lightweight Swing components. When the event is dispatched to 
> a heavyweight container, it's lightweight dispatcher retargets it to a 
> proper lightweight child.
>
> Given that we won't support transformations for heavyweight components 
> (BTW, it should also be reflected in JavaDoc), it's enough to care about 
> nativeContainer children only.


1) I'll add a remark to the new public methods that they only apply to 
lightweight components.
2) I'll study your remarks and decide if I'll add a check on 
nativeContainer.

I'll let you know if and when a version 3.2 is available.

Thanks,
Piet

>
>> Please let me know, so I can prepare a version 3.2 if needed (and add
>> the descriptions at the same time)
>
> 3.2 is only required if you make any significant changes based on the 
> current discussion.
>
> Thanks,
>
> Artem
>
>> Thanks,
>> Piet.
>>
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>
>>>> Hi Artem,
>>>>
>>>> The webrev for version 3.1:
>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>
>>>>
>>>>> Hi, Piet,
>>>>>
>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>> much, though :)
>>>>>
>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>>> translate. Could they also be static methods? It seems not, as I see a
>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>
>>>> I unified both methods and made them static after adding 
>>>> nativeContainer
>>>> as a parameter to both. Their signature is now:
>>>>
>>>> private static Point getXXXSpaceShift(Component target, Point dstPoint,
>>>> Container nativeContainer)
>>>>
>>>> (the nativeContainer argument is used in only one of the methods)
>>>>
>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>> iterating over the parent hierarchy, I added a check to "parent != 
>>>> null"
>>>> to also check "!(parent instanceof Window)".
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Please find a third version for the webrev here:
>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>
>>>>>> AWTAccessor removed again
>>>>>>
>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>
>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>> hierarchy translation value.
>>>>>>
>>>>>> Indented the try block
>>>>>>
>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>
>>>>>> Please review again
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Anthony,
>>>>>>>
>>>>>>>> Hi Piet,
>>>>>>>>
>>>>>>>> The version #2 looks very good.
>>>>>>>
>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>> It's
>>>>>>> missing something. Oh yes, I carried out a comprehensive manual test
>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>> jtreg
>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>
>>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>>> invalid and should not be used.
>>>>>>>
>>>>>>>>
>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>> AWTAccessor.
>>>>>>>>
>>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>>> right? That would be great.
>>>>>>>>
>>>>>>>
>>>>>>> Yes
>>>>>>>
>>>>>>>>
>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>> Container implementation does nothing.
>>>>>>>>>
>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>
>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>>> course be removed.
>>>>>>>>
>>>>>>>> I like the proposal.
>>>>>>>
>>>>>>> As said, something was missing: A Container.toRenderedSpace(point) 
>>>>>>> is
>>>>>>> needed as well. This method must return the normal transformed 
>>>>>>> point,
>>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>>> point.
>>>>>>>
>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>>> option open for implementers to choose for a transformation other
>>>>>>> than
>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to know 
>>>>>>> how
>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>> point).
>>>>>>>
>>>>>>>>
>>>>>>>> A minor comment regarding the code:
>>>>>>>>
>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>
>>>>>>>> I suggest to use the getContainer() method instead. If the comp is 
>>>>>>>> a
>>>>>>>> window, the getParent() may actually return an owner of the window,
>>>>>>>> which we certainly don't want to deal with.
>>>>>>>
>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>
>>>>>>>>
>>>>>>>> Also, please make sure you format the code according the 
>>>>>>>> guidelines:
>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>> correctly indented.
>>>>>>>
>>>>>>> This I was wondering about: should I or shouldn't I (touch code that
>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>
>>>>>>>>
>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>
>>>>>>>
>>>>>>> Ok, I'm working on version 3. And this time actually testing against
>>>>>>> this same version 3! I'm still working on some more simple jtreg 
>>>>>>> test
>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>> --
>>>>>>>> best regards,
>>>>>>>> Anthony
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Please let me know if you agree.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
> 




From sergey.malenkov at sun.com  Thu Feb 18 14:47:19 2010
From: sergey.malenkov at sun.com (sergey.malenkov at sun.com)
Date: Thu, 18 Feb 2010 14:47:19 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 4498236: RFE: Provide a toString
	method for	PropertyChangeEvent and other classes
Message-ID: <20100218144803.989634267A@hg.openjdk.java.net>

Changeset: e8340332745e
Author:    malenkov
Date:      2010-02-18 17:46 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/e8340332745e

4498236: RFE: Provide a toString method for PropertyChangeEvent and other classes
Reviewed-by: peterz

! src/share/classes/java/beans/BeanDescriptor.java
! src/share/classes/java/beans/EventSetDescriptor.java
! src/share/classes/java/beans/FeatureDescriptor.java
! src/share/classes/java/beans/IndexedPropertyChangeEvent.java
! src/share/classes/java/beans/IndexedPropertyDescriptor.java
! src/share/classes/java/beans/MethodDescriptor.java
! src/share/classes/java/beans/PropertyChangeEvent.java
! src/share/classes/java/beans/PropertyDescriptor.java
+ test/java/beans/Introspector/Test4498236.java



From Alexander.Potochkin at Sun.COM  Wed Feb 24 13:41:05 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 24 Feb 2010 16:41:05 +0300
Subject: <Swing Dev> <AWT Dev>
	Fw:	reviewrequestfor6899434:Addaffinetransformsupport to JLayer
In-Reply-To: <53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
Message-ID: <4B852C71.1090402@sun.com>

Hello Piet and the team

While the AWT part of the fix is clear and almost done
there are some alternatives
how we should make the best out of it on the Swing side

To make the best decision and get the early feedback from the community
I propose to split the generic support of mouse events
from adding getTransform()/setTransform() on the Swing side.

This is one of the fix which is better to be done step by step.

I filed a new RFE #6929295:
Generic support of mouse event transformation for AWT/Swing

Fixing it will enable the users to easily use
affine transforms for custom Swing components,
which is a fine addition itself.

The next steps will be certainly discussed
shortly after that

Piet, could you please make a new webrev for 6929295?

It should be basically the same fix as for 6899434
but with no changes in JLayer

It would be really great if we manage to do only with
toLayoutSpace()/toRenderedSpace() methods
without using JComponent.inverseTransformVisibleRectangle()

I hope you can emulate it by transforming the corner points of the 
rectangle with toLayoutSpace() method and using its bounds
inside the JComponent.computeVisibleRect() method.

For the default case (no transforms, rectangles only) it will be cheap
and will simplify the usage of the new feature for the Swing developers.

Thanks
alexp

>
> Hi Artem
>
>
>>
>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>> Hi Artem
>>>
>>>> Hi, Piet,
>>>>
>>>> the fix looks pretty good in general. Some small comments:
>>>>
>>>> 1. As we're about to introduce 2 new public methods into Container, we
>>>> need to provide a description of "layout space" and "render space". I
>>>> hope you or Alex will take care of this.
>>>
>>> What about the following descriptions?
>>>
>>> Layout space refers to user space (coordinates in the layout system).
>>> Rendered space refers to device space (coordinates on the screen).
>>> Please see (link to) AffineTransform.
>>
>> Probably, we should mention that layout coordinates are the ones used
>> by LayoutManager and other Container stuff. For example,
>> Component.getBounds() always returns layout rectangle, not rendered one.
>
> Ok, good addition. I'll add that clarification.
>
>>
>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>> well?
>>>
>>> No. toRenderedSpace() is a direct transformation with any of
>>> AffineTransform's transform() methods.
>>> This in contrast to inverse operations as used in toLayoutSpace(), like
>>> AffineTransform's createInverse() and inverseTransform() methods that
>>> may throw this exception.
>>
>> It depends on what we consider a forward transform and a reverse
>> transform :) And don't forget there may be non-affine transforms...
>
> Any transform, be it affine or non-affine is able by definition to
> transform, otherwise it's not a transform :-)
>
> Only inverse transform can be problematic. That is, when two different
> points, after transformation, result in the same point. Valid during
> transform. But impossible to do an inverse. Analogous to multiplying by
> zero is valid, but the operation can't be inversed.
>
>>
>>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>>> or up to the nativeContainer?
>>>
>>> Good point. For testing I added a test "not nativeContainer" to the null
>>> test and everything still works (in my own test suite that is far more
>>> complex than the provided jtreg test cases).
>>>
>>> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
>>> traversal that is analogous to the traversal there.
>>>
>>> In general, I'm not sure about the role of "nativeContainer" and how it
>>> is used. For example, I don't know if (one or more) native containers
>>> can be present in the hierachy between a Window and the lowest child
>>> component. Or is the top Window always the native container? If this is
>>> not the case, could you depict some hierarchy example where a native
>>> container is a child somewhere in the hierarchy of a JLayer's view? Then
>>> I can do a more comprehensive test.
>>
>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>> is the container, always heavyweight, which is served by the
>> dispatcher. An obvious example is how all the mouse events are
>> dispatched: we (AWT) receive events for heavyweight components only as
>> the underlying OS isn't aware of our lightweight Swing components.
>> When the event is dispatched to a heavyweight container, it's
>> lightweight dispatcher retargets it to a proper lightweight child.
>>
>> Given that we won't support transformations for heavyweight components
>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>> about nativeContainer children only.
>
>
> 1) I'll add a remark to the new public methods that they only apply to
> lightweight components.
> 2) I'll study your remarks and decide if I'll add a check on
> nativeContainer.
>
> I'll let you know if and when a version 3.2 is available.
>
> Thanks,
> Piet
>
>>
>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>> the descriptions at the same time)
>>
>> 3.2 is only required if you make any significant changes based on the
>> current discussion.
>>
>> Thanks,
>>
>> Artem
>>
>>> Thanks,
>>> Piet.
>>>
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>
>>>>> Hi Artem,
>>>>>
>>>>> The webrev for version 3.1:
>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>
>>>>>
>>>>>> Hi, Piet,
>>>>>>
>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>> much, though :)
>>>>>>
>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point to
>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>> see a
>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>
>>>>> I unified both methods and made them static after adding
>>>>> nativeContainer
>>>>> as a parameter to both. Their signature is now:
>>>>>
>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>> dstPoint,
>>>>> Container nativeContainer)
>>>>>
>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>
>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>> null"
>>>>> to also check "!(parent instanceof Window)".
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Please find a third version for the webrev here:
>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>
>>>>>>> AWTAccessor removed again
>>>>>>>
>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>
>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>> hierarchy translation value.
>>>>>>>
>>>>>>> Indented the try block
>>>>>>>
>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>
>>>>>>> Please review again
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Anthony,
>>>>>>>>
>>>>>>>>> Hi Piet,
>>>>>>>>>
>>>>>>>>> The version #2 looks very good.
>>>>>>>>
>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>>> It's
>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>> test
>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>> jtreg
>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>
>>>>>>>> I'll try to manually add a remark to that webrev to state that it's
>>>>>>>> invalid and should not be used.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>>> AWTAccessor.
>>>>>>>>>
>>>>>>>>> So that the Component.transform is moved over to the JLayer class,
>>>>>>>>> right? That would be great.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Yes
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>
>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>
>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will of
>>>>>>>>>> course be removed.
>>>>>>>>>
>>>>>>>>> I like the proposal.
>>>>>>>>
>>>>>>>> As said, something was missing: A
>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>> point,
>>>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>>>> point.
>>>>>>>>
>>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves the
>>>>>>>> option open for implementers to choose for a transformation other
>>>>>>>> than
>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>> know how
>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>> point).
>>>>>>>>
>>>>>>>>>
>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>
>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>
>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>> is a
>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>> window,
>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>
>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>> guidelines:
>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>> correctly indented.
>>>>>>>>
>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>> that
>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>> against
>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>> test
>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>> --
>>>>>>>>> best regards,
>>>>>>>>> Anthony
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>



From pbhome at ziggo.nl  Wed Feb 24 14:24:36 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Wed, 24 Feb 2010 15:24:36 +0100
Subject: <Swing Dev> <AWT
	Dev>	Fw:reviewrequestfor6899434:Addaffinetransformsupport to JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
	<4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
	<4B852C71.1090402@sun.com>
Message-ID: <C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>

Hi All,



> Hello Piet and the team
>
> While the AWT part of the fix is clear and almost done
> there are some alternatives
> how we should make the best out of it on the Swing side
>
> To make the best decision and get the early feedback from the community
> I propose to split the generic support of mouse events
> from adding getTransform()/setTransform() on the Swing side.
>
> This is one of the fix which is better to be done step by step.
>
> I filed a new RFE #6929295:
> Generic support of mouse event transformation for AWT/Swing
>
> Fixing it will enable the users to easily use
> affine transforms for custom Swing components,
> which is a fine addition itself.
>
> The next steps will be certainly discussed
> shortly after that
>
> Piet, could you please make a new webrev for 6929295?
>
> It should be basically the same fix as for 6899434
> but with no changes in JLayer

Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/

(It is created from the same respository, hence the misleading name insiade 
the webrev)

I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet 
publicly available?

Changes versus the last version v3.2:

1) Added a check on nativeContainer (I don't think it is necessary, but it 
doesn't hurt)
2) Edited the API doc for the two new methods

>
> It would be really great if we manage to do only with
> toLayoutSpace()/toRenderedSpace() methods
> without using JComponent.inverseTransformVisibleRectangle()
>
> I hope you can emulate it by transforming the corner points of the 
> rectangle with toLayoutSpace() method and using its bounds
> inside the JComponent.computeVisibleRect() method.

Technically such a computation is possible. However, the 
JLayer.inverseTransformVisibleRectangle() does something more:
it intersect the resulting rectangle with the transformed view bounds. But 
let's discuss that later.

>
> For the default case (no transforms, rectangles only) it will be cheap
> and will simplify the usage of the new feature for the Swing developers.
>
> Thanks
> alexp
>
>>
>> Hi Artem
>>
>>
>>>
>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>> Hi Artem
>>>>
>>>>> Hi, Piet,
>>>>>
>>>>> the fix looks pretty good in general. Some small comments:
>>>>>
>>>>> 1. As we're about to introduce 2 new public methods into Container, we
>>>>> need to provide a description of "layout space" and "render space". I
>>>>> hope you or Alex will take care of this.
>>>>
>>>> What about the following descriptions?
>>>>
>>>> Layout space refers to user space (coordinates in the layout system).
>>>> Rendered space refers to device space (coordinates on the screen).
>>>> Please see (link to) AffineTransform.
>>>
>>> Probably, we should mention that layout coordinates are the ones used
>>> by LayoutManager and other Container stuff. For example,
>>> Component.getBounds() always returns layout rectangle, not rendered one.
>>
>> Ok, good addition. I'll add that clarification.
>>
>>>
>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>> well?
>>>>
>>>> No. toRenderedSpace() is a direct transformation with any of
>>>> AffineTransform's transform() methods.
>>>> This in contrast to inverse operations as used in toLayoutSpace(), like
>>>> AffineTransform's createInverse() and inverseTransform() methods that
>>>> may throw this exception.
>>>
>>> It depends on what we consider a forward transform and a reverse
>>> transform :) And don't forget there may be non-affine transforms...
>>
>> Any transform, be it affine or non-affine is able by definition to
>> transform, otherwise it's not a transform :-)
>>
>> Only inverse transform can be problematic. That is, when two different
>> points, after transformation, result in the same point. Valid during
>> transform. But impossible to do an inverse. Analogous to multiplying by
>> zero is valid, but the operation can't be inversed.
>>
>>>
>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>>>> or up to the nativeContainer?
>>>>
>>>> Good point. For testing I added a test "not nativeContainer" to the 
>>>> null
>>>> test and everything still works (in my own test suite that is far more
>>>> complex than the provided jtreg test cases).
>>>>
>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should do a
>>>> traversal that is analogous to the traversal there.
>>>>
>>>> In general, I'm not sure about the role of "nativeContainer" and how it
>>>> is used. For example, I don't know if (one or more) native containers
>>>> can be present in the hierachy between a Window and the lowest child
>>>> component. Or is the top Window always the native container? If this is
>>>> not the case, could you depict some hierarchy example where a native
>>>> container is a child somewhere in the hierarchy of a JLayer's view? 
>>>> Then
>>>> I can do a more comprehensive test.
>>>
>>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>>> is the container, always heavyweight, which is served by the
>>> dispatcher. An obvious example is how all the mouse events are
>>> dispatched: we (AWT) receive events for heavyweight components only as
>>> the underlying OS isn't aware of our lightweight Swing components.
>>> When the event is dispatched to a heavyweight container, it's
>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>
>>> Given that we won't support transformations for heavyweight components
>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>> about nativeContainer children only.
>>
>>
>> 1) I'll add a remark to the new public methods that they only apply to
>> lightweight components.
>> 2) I'll study your remarks and decide if I'll add a check on
>> nativeContainer.
>>
>> I'll let you know if and when a version 3.2 is available.
>>
>> Thanks,
>> Piet
>>
>>>
>>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>>> the descriptions at the same time)
>>>
>>> 3.2 is only required if you make any significant changes based on the
>>> current discussion.
>>>
>>> Thanks,
>>>
>>> Artem
>>>
>>>> Thanks,
>>>> Piet.
>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>
>>>>>> Hi Artem,
>>>>>>
>>>>>> The webrev for version 3.1:
>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>
>>>>>>
>>>>>>> Hi, Piet,
>>>>>>>
>>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>>> much, though :)
>>>>>>>
>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a Point 
>>>>>>> to
>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>> see a
>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>
>>>>>> I unified both methods and made them static after adding
>>>>>> nativeContainer
>>>>>> as a parameter to both. Their signature is now:
>>>>>>
>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>> dstPoint,
>>>>>> Container nativeContainer)
>>>>>>
>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>
>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>> null"
>>>>>> to also check "!(parent instanceof Window)".
>>>>>>
>>>>>> Thanks,
>>>>>> Piet
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Please find a third version for the webrev here:
>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>
>>>>>>>> AWTAccessor removed again
>>>>>>>>
>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>
>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>>> hierarchy translation value.
>>>>>>>>
>>>>>>>> Indented the try block
>>>>>>>>
>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>
>>>>>>>> Please review again
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Anthony,
>>>>>>>>>
>>>>>>>>>> Hi Piet,
>>>>>>>>>>
>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>
>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>>>> It's
>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>> test
>>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>>> jtreg
>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>
>>>>>>>>> I'll try to manually add a remark to that webrev to state that 
>>>>>>>>> it's
>>>>>>>>> invalid and should not be used.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>
>>>>>>>>>> So that the Component.transform is moved over to the JLayer 
>>>>>>>>>> class,
>>>>>>>>>> right? That would be great.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Yes
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>
>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>
>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms() will 
>>>>>>>>>>> of
>>>>>>>>>>> course be removed.
>>>>>>>>>>
>>>>>>>>>> I like the proposal.
>>>>>>>>>
>>>>>>>>> As said, something was missing: A
>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>> point,
>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse transformed
>>>>>>>>> point.
>>>>>>>>>
>>>>>>>>> And yes, like Artem pointed out in an earlier post, this leaves 
>>>>>>>>> the
>>>>>>>>> option open for implementers to choose for a transformation other
>>>>>>>>> than
>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>> know how
>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>> point).
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>
>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>
>>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>>> is a
>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>> window,
>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>
>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>> guidelines:
>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>> correctly indented.
>>>>>>>>>
>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>> that
>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>> against
>>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>>> test
>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> best regards,
>>>>>>>>>> Anthony
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
> 




From Alexander.Potochkin at Sun.COM  Wed Feb 24 14:44:06 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 24 Feb 2010 17:44:06 +0300
Subject: <Swing Dev>
	<AWT	Dev>	Fw:reviewrequestfor6899434:Addaffinetransformsupport
	to JLayer
In-Reply-To: <C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J> <4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
Message-ID: <4B853B36.6010303@sun.com>

Hello Piet

>> Piet, could you please make a new webrev for 6929295?
>>
>> It should be basically the same fix as for 6899434
>> but with no changes in JLayer
>
> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/

The main idea is to enable users to easily use transforms in custom 
Swing components, so we need all the stuff for the RM, ToolTipManager etc..

just JLayer is to be excluded

>
> (It is created from the same respository, hence the misleading name
> insiade the webrev)
>
> I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet
> publicly available?

It usually takes a couple of days to show up in the database

>
> Changes versus the last version v3.2:
>
> 1) Added a check on nativeContainer (I don't think it is necessary, but
> it doesn't hurt)
> 2) Edited the API doc for the two new methods



>>
>> It would be really great if we manage to do only with
>> toLayoutSpace()/toRenderedSpace() methods
>> without using JComponent.inverseTransformVisibleRectangle()
>>
>> I hope you can emulate it by transforming the corner points of the
>> rectangle with toLayoutSpace() method and using its bounds
>> inside the JComponent.computeVisibleRect() method.
>
> Technically such a computation is possible. However, the
> JLayer.inverseTransformVisibleRectangle() does something more:
> it intersect the resulting rectangle with the transformed view bounds.
> But let's discuss that later.

Is it possible to implement this computation right now?

I am afraid we also need at least one simple test
with a custom Swing component with overridden 
toLayoutSpace()/toRenderedSpace()

Thanks much and sorry for the confusion!

alexp

>
>>
>> For the default case (no transforms, rectangles only) it will be cheap
>> and will simplify the usage of the new feature for the Swing developers.
>>
>> Thanks
>> alexp
>>
>>>
>>> Hi Artem
>>>
>>>
>>>>
>>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>>> Hi Artem
>>>>>
>>>>>> Hi, Piet,
>>>>>>
>>>>>> the fix looks pretty good in general. Some small comments:
>>>>>>
>>>>>> 1. As we're about to introduce 2 new public methods into
>>>>>> Container, we
>>>>>> need to provide a description of "layout space" and "render space". I
>>>>>> hope you or Alex will take care of this.
>>>>>
>>>>> What about the following descriptions?
>>>>>
>>>>> Layout space refers to user space (coordinates in the layout system).
>>>>> Rendered space refers to device space (coordinates on the screen).
>>>>> Please see (link to) AffineTransform.
>>>>
>>>> Probably, we should mention that layout coordinates are the ones used
>>>> by LayoutManager and other Container stuff. For example,
>>>> Component.getBounds() always returns layout rectangle, not rendered
>>>> one.
>>>
>>> Ok, good addition. I'll add that clarification.
>>>
>>>>
>>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>>> well?
>>>>>
>>>>> No. toRenderedSpace() is a direct transformation with any of
>>>>> AffineTransform's transform() methods.
>>>>> This in contrast to inverse operations as used in toLayoutSpace(),
>>>>> like
>>>>> AffineTransform's createInverse() and inverseTransform() methods that
>>>>> may throw this exception.
>>>>
>>>> It depends on what we consider a forward transform and a reverse
>>>> transform :) And don't forget there may be non-affine transforms...
>>>
>>> Any transform, be it affine or non-affine is able by definition to
>>> transform, otherwise it's not a transform :-)
>>>
>>> Only inverse transform can be problematic. That is, when two different
>>> points, after transformation, result in the same point. Valid during
>>> transform. But impossible to do an inverse. Analogous to multiplying by
>>> zero is valid, but the operation can't be inversed.
>>>
>>>>
>>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to null
>>>>>> or up to the nativeContainer?
>>>>>
>>>>> Good point. For testing I added a test "not nativeContainer" to the
>>>>> null
>>>>> test and everything still works (in my own test suite that is far more
>>>>> complex than the provided jtreg test cases).
>>>>>
>>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should
>>>>> do a
>>>>> traversal that is analogous to the traversal there.
>>>>>
>>>>> In general, I'm not sure about the role of "nativeContainer" and
>>>>> how it
>>>>> is used. For example, I don't know if (one or more) native containers
>>>>> can be present in the hierachy between a Window and the lowest child
>>>>> component. Or is the top Window always the native container? If
>>>>> this is
>>>>> not the case, could you depict some hierarchy example where a native
>>>>> container is a child somewhere in the hierarchy of a JLayer's view?
>>>>> Then
>>>>> I can do a more comprehensive test.
>>>>
>>>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>>>> is the container, always heavyweight, which is served by the
>>>> dispatcher. An obvious example is how all the mouse events are
>>>> dispatched: we (AWT) receive events for heavyweight components only as
>>>> the underlying OS isn't aware of our lightweight Swing components.
>>>> When the event is dispatched to a heavyweight container, it's
>>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>>
>>>> Given that we won't support transformations for heavyweight components
>>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>>> about nativeContainer children only.
>>>
>>>
>>> 1) I'll add a remark to the new public methods that they only apply to
>>> lightweight components.
>>> 2) I'll study your remarks and decide if I'll add a check on
>>> nativeContainer.
>>>
>>> I'll let you know if and when a version 3.2 is available.
>>>
>>> Thanks,
>>> Piet
>>>
>>>>
>>>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>>>> the descriptions at the same time)
>>>>
>>>> 3.2 is only required if you make any significant changes based on the
>>>> current discussion.
>>>>
>>>> Thanks,
>>>>
>>>> Artem
>>>>
>>>>> Thanks,
>>>>> Piet.
>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>>
>>>>>>> Hi Artem,
>>>>>>>
>>>>>>> The webrev for version 3.1:
>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>>
>>>>>>>
>>>>>>>> Hi, Piet,
>>>>>>>>
>>>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>>>> much, though :)
>>>>>>>>
>>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a
>>>>>>>> Point to
>>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>>> see a
>>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>>
>>>>>>> I unified both methods and made them static after adding
>>>>>>> nativeContainer
>>>>>>> as a parameter to both. Their signature is now:
>>>>>>>
>>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>>> dstPoint,
>>>>>>> Container nativeContainer)
>>>>>>>
>>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>>
>>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>>> null"
>>>>>>> to also check "!(parent instanceof Window)".
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Please find a third version for the webrev here:
>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>>
>>>>>>>>> AWTAccessor removed again
>>>>>>>>>
>>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>>
>>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>>>> hierarchy translation value.
>>>>>>>>>
>>>>>>>>> Indented the try block
>>>>>>>>>
>>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>>
>>>>>>>>> Please review again
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi Anthony,
>>>>>>>>>>
>>>>>>>>>>> Hi Piet,
>>>>>>>>>>>
>>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>>
>>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't work.
>>>>>>>>>> It's
>>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>>> test
>>>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>>>> jtreg
>>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>>
>>>>>>>>>> I'll try to manually add a remark to that webrev to state that
>>>>>>>>>> it's
>>>>>>>>>> invalid and should not be used.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>>> 1) The implementation in version 2 will be used but without the
>>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>>
>>>>>>>>>>> So that the Component.transform is moved over to the JLayer
>>>>>>>>>>> class,
>>>>>>>>>>> right? That would be great.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Yes
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and the
>>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>>
>>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>>
>>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms()
>>>>>>>>>>>> will of
>>>>>>>>>>>> course be removed.
>>>>>>>>>>>
>>>>>>>>>>> I like the proposal.
>>>>>>>>>>
>>>>>>>>>> As said, something was missing: A
>>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>>> point,
>>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse
>>>>>>>>>> transformed
>>>>>>>>>> point.
>>>>>>>>>>
>>>>>>>>>> And yes, like Artem pointed out in an earlier post, this
>>>>>>>>>> leaves the
>>>>>>>>>> option open for implementers to choose for a transformation other
>>>>>>>>>> than
>>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>>> know how
>>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>>> point).
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>>
>>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>>
>>>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>>>> is a
>>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>>> window,
>>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>>
>>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very good.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>>> guidelines:
>>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>>> correctly indented.
>>>>>>>>>>
>>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>>> that
>>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>>> against
>>>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>>>> test
>>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> best regards,
>>>>>>>>>>> Anthony
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>



From Anthony.Petrov at Sun.COM  Wed Feb 24 14:49:38 2010
From: Anthony.Petrov at Sun.COM (Anthony Petrov)
Date: Wed, 24 Feb 2010 17:49:38 +0300
Subject: <Swing Dev>
	<AWT	Dev>	Fw:reviewrequestfor6899434:Addaffinetransformsupport
	to JLayer
In-Reply-To: <C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J> <4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
Message-ID: <4B853C82.4010309@sun.com>

Hi Piet, Alex,

On 02/24/2010 05:24 PM, Piet Blok wrote:
>> To make the best decision and get the early feedback from the community
>> I propose to split the generic support of mouse events
>> from adding getTransform()/setTransform() on the Swing side.
>>
>> This is one of the fix which is better to be done step by step.
>>
>> Fixing it will enable the users to easily use
>> affine transforms for custom Swing components,
>> which is a fine addition itself.

Strongly agree!


>> Piet, could you please make a new webrev for 6929295?
>>
> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/

The fix looks fine. Just been wondering what testing has been performed 
with that fix? Did you try running swing and awt applications with some 
components in their windows, and see if all clicks get correctly 
delivered to lw and hw components?

--
best regards,
Anthony


From pbhome at ziggo.nl  Wed Feb 24 15:29:17 2010
From: pbhome at ziggo.nl (Piet Blok)
Date: Wed, 24 Feb 2010 16:29:17 +0100
Subject: <Swing Dev>
	<AWT	Dev>Fw:reviewrequestfor6899434:Addaffinetransformsupport	to
	JLayer
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com>
	<57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com>
	<B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J>
	<4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J>
	<4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J>
	<4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J>
	<4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J>
	<4B853B36.6010303@sun.com>
Message-ID: <3CF1C66CF4E44910A24EAF4BF7C34A94@DB35TT0J>

Hi Alex, Anthony and others,

Aha, I misinterpreted the request to only an awt change.

I'll start working on an uptaed implementation on the swing side 
(RepaintManager, JPopupMenu, ToolTipManager and JComponent), only using 
toLayoutSpace and toRendereredSpace in Container.
Then I'll also be able to create a simple test with some custom transforming 
component.

This will take some more time :-)

Thanks Piet


> Hello Piet
>
>>> Piet, could you please make a new webrev for 6929295?
>>>
>>> It should be basically the same fix as for 6899434
>>> but with no changes in JLayer
>>
>> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/
>
> The main idea is to enable users to easily use transforms in custom Swing 
> components, so we need all the stuff for the RM, ToolTipManager etc..
>
> just JLayer is to be excluded
>
>>
>> (It is created from the same respository, hence the misleading name
>> insiade the webrev)
>>
>> I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet
>> publicly available?
>
> It usually takes a couple of days to show up in the database
>
>>
>> Changes versus the last version v3.2:
>>
>> 1) Added a check on nativeContainer (I don't think it is necessary, but
>> it doesn't hurt)
>> 2) Edited the API doc for the two new methods
>
>
>
>>>
>>> It would be really great if we manage to do only with
>>> toLayoutSpace()/toRenderedSpace() methods
>>> without using JComponent.inverseTransformVisibleRectangle()
>>>
>>> I hope you can emulate it by transforming the corner points of the
>>> rectangle with toLayoutSpace() method and using its bounds
>>> inside the JComponent.computeVisibleRect() method.
>>
>> Technically such a computation is possible. However, the
>> JLayer.inverseTransformVisibleRectangle() does something more:
>> it intersect the resulting rectangle with the transformed view bounds.
>> But let's discuss that later.
>
> Is it possible to implement this computation right now?
>
> I am afraid we also need at least one simple test
> with a custom Swing component with overridden 
> toLayoutSpace()/toRenderedSpace()
>
> Thanks much and sorry for the confusion!
>
> alexp
>
>>
>>>
>>> For the default case (no transforms, rectangles only) it will be cheap
>>> and will simplify the usage of the new feature for the Swing developers.
>>>
>>> Thanks
>>> alexp
>>>
>>>>
>>>> Hi Artem
>>>>
>>>>
>>>>>
>>>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>>>> Hi Artem
>>>>>>
>>>>>>> Hi, Piet,
>>>>>>>
>>>>>>> the fix looks pretty good in general. Some small comments:
>>>>>>>
>>>>>>> 1. As we're about to introduce 2 new public methods into
>>>>>>> Container, we
>>>>>>> need to provide a description of "layout space" and "render space". 
>>>>>>> I
>>>>>>> hope you or Alex will take care of this.
>>>>>>
>>>>>> What about the following descriptions?
>>>>>>
>>>>>> Layout space refers to user space (coordinates in the layout system).
>>>>>> Rendered space refers to device space (coordinates on the screen).
>>>>>> Please see (link to) AffineTransform.
>>>>>
>>>>> Probably, we should mention that layout coordinates are the ones used
>>>>> by LayoutManager and other Container stuff. For example,
>>>>> Component.getBounds() always returns layout rectangle, not rendered
>>>>> one.
>>>>
>>>> Ok, good addition. I'll add that clarification.
>>>>
>>>>>
>>>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>>>> well?
>>>>>>
>>>>>> No. toRenderedSpace() is a direct transformation with any of
>>>>>> AffineTransform's transform() methods.
>>>>>> This in contrast to inverse operations as used in toLayoutSpace(),
>>>>>> like
>>>>>> AffineTransform's createInverse() and inverseTransform() methods that
>>>>>> may throw this exception.
>>>>>
>>>>> It depends on what we consider a forward transform and a reverse
>>>>> transform :) And don't forget there may be non-affine transforms...
>>>>
>>>> Any transform, be it affine or non-affine is able by definition to
>>>> transform, otherwise it's not a transform :-)
>>>>
>>>> Only inverse transform can be problematic. That is, when two different
>>>> points, after transformation, result in the same point. Valid during
>>>> transform. But impossible to do an inverse. Analogous to multiplying by
>>>> zero is valid, but the operation can't be inversed.
>>>>
>>>>>
>>>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to 
>>>>>>> null
>>>>>>> or up to the nativeContainer?
>>>>>>
>>>>>> Good point. For testing I added a test "not nativeContainer" to the
>>>>>> null
>>>>>> test and everything still works (in my own test suite that is far 
>>>>>> more
>>>>>> complex than the provided jtreg test cases).
>>>>>>
>>>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should
>>>>>> do a
>>>>>> traversal that is analogous to the traversal there.
>>>>>>
>>>>>> In general, I'm not sure about the role of "nativeContainer" and
>>>>>> how it
>>>>>> is used. For example, I don't know if (one or more) native containers
>>>>>> can be present in the hierachy between a Window and the lowest child
>>>>>> component. Or is the top Window always the native container? If
>>>>>> this is
>>>>>> not the case, could you depict some hierarchy example where a native
>>>>>> container is a child somewhere in the hierarchy of a JLayer's view?
>>>>>> Then
>>>>>> I can do a more comprehensive test.
>>>>>
>>>>> nativeContainer is a basic part of LightweightDispatcher machinery: it
>>>>> is the container, always heavyweight, which is served by the
>>>>> dispatcher. An obvious example is how all the mouse events are
>>>>> dispatched: we (AWT) receive events for heavyweight components only as
>>>>> the underlying OS isn't aware of our lightweight Swing components.
>>>>> When the event is dispatched to a heavyweight container, it's
>>>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>>>
>>>>> Given that we won't support transformations for heavyweight components
>>>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>>>> about nativeContainer children only.
>>>>
>>>>
>>>> 1) I'll add a remark to the new public methods that they only apply to
>>>> lightweight components.
>>>> 2) I'll study your remarks and decide if I'll add a check on
>>>> nativeContainer.
>>>>
>>>> I'll let you know if and when a version 3.2 is available.
>>>>
>>>> Thanks,
>>>> Piet
>>>>
>>>>>
>>>>>> Please let me know, so I can prepare a version 3.2 if needed (and add
>>>>>> the descriptions at the same time)
>>>>>
>>>>> 3.2 is only required if you make any significant changes based on the
>>>>> current discussion.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Artem
>>>>>
>>>>>> Thanks,
>>>>>> Piet.
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Artem
>>>>>>>
>>>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>>>
>>>>>>>> Hi Artem,
>>>>>>>>
>>>>>>>> The webrev for version 3.1:
>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi, Piet,
>>>>>>>>>
>>>>>>>>> the 3rd version looks really great! I haven't looked to Swing code
>>>>>>>>> much, though :)
>>>>>>>>>
>>>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a
>>>>>>>>> Point to
>>>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>>>> see a
>>>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>>>
>>>>>>>> I unified both methods and made them static after adding
>>>>>>>> nativeContainer
>>>>>>>> as a parameter to both. Their signature is now:
>>>>>>>>
>>>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>>>> dstPoint,
>>>>>>>> Container nativeContainer)
>>>>>>>>
>>>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>>>
>>>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>>>> null"
>>>>>>>> to also check "!(parent instanceof Window)".
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Piet
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> Artem
>>>>>>>>>
>>>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Please find a third version for the webrev here:
>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>>>
>>>>>>>>>> AWTAccessor removed again
>>>>>>>>>>
>>>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>>>
>>>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but getParent() in
>>>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>>>> retargetMouseEvent which itself uses getParent() when finding the
>>>>>>>>>> hierarchy translation value.
>>>>>>>>>>
>>>>>>>>>> Indented the try block
>>>>>>>>>>
>>>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>>>
>>>>>>>>>> Please review again
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Piet
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>
>>>>>>>>>>>> Hi Piet,
>>>>>>>>>>>>
>>>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>>>
>>>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't 
>>>>>>>>>>> work.
>>>>>>>>>>> It's
>>>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>>>> test
>>>>>>>>>>> but the test setup was wrong: I tested against the version 1! (A
>>>>>>>>>>> jtreg
>>>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>>>
>>>>>>>>>>> I'll try to manually add a remark to that webrev to state that
>>>>>>>>>>> it's
>>>>>>>>>>> invalid and should not be used.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>>>> 1) The implementation in version 2 will be used but without 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>>>
>>>>>>>>>>>> So that the Component.transform is moved over to the JLayer
>>>>>>>>>>>> class,
>>>>>>>>>>>> right? That would be great.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Yes
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected and 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will remain
>>>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms()
>>>>>>>>>>>>> will of
>>>>>>>>>>>>> course be removed.
>>>>>>>>>>>>
>>>>>>>>>>>> I like the proposal.
>>>>>>>>>>>
>>>>>>>>>>> As said, something was missing: A
>>>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>>>> point,
>>>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse
>>>>>>>>>>> transformed
>>>>>>>>>>> point.
>>>>>>>>>>>
>>>>>>>>>>> And yes, like Artem pointed out in an earlier post, this
>>>>>>>>>>> leaves the
>>>>>>>>>>> option open for implementers to choose for a transformation 
>>>>>>>>>>> other
>>>>>>>>>>> than
>>>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>>>> know how
>>>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>>>> point).
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>>>
>>>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>>>
>>>>>>>>>>>> I suggest to use the getContainer() method instead. If the comp
>>>>>>>>>>>> is a
>>>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>>>> window,
>>>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>>>
>>>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very 
>>>>>>>>>>> good.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>>>> guidelines:
>>>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>>>> correctly indented.
>>>>>>>>>>>
>>>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>>>> that
>>>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>>>> against
>>>>>>>>>>> this same version 3! I'm still working on some more simple jtreg
>>>>>>>>>>> test
>>>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> best regards,
>>>>>>>>>>>> Anthony
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
> 




From Alexander.Potochkin at Sun.COM  Wed Feb 24 15:39:48 2010
From: Alexander.Potochkin at Sun.COM (Alexander Potochkin)
Date: Wed, 24 Feb 2010 18:39:48 +0300
Subject: <Swing Dev>
	<AWT	Dev>Fw:reviewrequestfor6899434:Addaffinetransformsupport
	to	JLayer
In-Reply-To: <3CF1C66CF4E44910A24EAF4BF7C34A94@DB35TT0J>
References: <1C62018E69864F7C94E8C7619967B87B@DB35TT0J>
	<4B714714.3040108@sun.com> <57019EF35B914E098ED8B3602DD418C5@DB35TT0J>
	<4B73B563.7080002@sun.com> <B6706DE6634B4E50B6ED7A2A0C0C98B6@DB35TT0J>
	<0A8802016EC84B1EAE45138B9B8572AC@DB35TT0J> <4B7442D3.3040709@sun.com>
	<7BDDC09250914327BD9FA1DE86D53E9D@DB35TT0J> <4B7A946A.6000503@sun.com>
	<1ECCC728562043B8A1FAFB972DDA2DB0@DB35TT0J> <4B7ABFAD.8060403@sun.com>
	<53918E681BAF475E99134FF75A4BB5E7@DB35TT0J> <4B852C71.1090402@sun.com>
	<C2D517ADDBD9400D88C328D1889596B2@DB35TT0J> <4B853B36.6010303@sun.com>
	<3CF1C66CF4E44910A24EAF4BF7C34A94@DB35TT0J>
Message-ID: <4B854844.5070300@sun.com>


> Hi Alex, Anthony and others,

Hello Piet

>
> Aha, I misinterpreted the request to only an awt change.
>
> I'll start working on an uptaed implementation on the swing side
> (RepaintManager, JPopupMenu, ToolTipManager and JComponent), only using
> toLayoutSpace and toRendereredSpace in Container.
> Then I'll also be able to create a simple test with some custom
> transforming component.
>
> This will take some more time :-)

Sure

Thanks much!
alexp

>
> Thanks Piet
>
>
>> Hello Piet
>>
>>>> Piet, could you please make a new webrev for 6929295?
>>>>
>>>> It should be basically the same fix as for 6899434
>>>> but with no changes in JLayer
>>>
>>> Done. Please see here http://www.pbjar.org/OpenJDK/6929295/webrev/
>>
>> The main idea is to enable users to easily use transforms in custom
>> Swing components, so we need all the stuff for the RM, ToolTipManager
>> etc..
>>
>> just JLayer is to be excluded
>>
>>>
>>> (It is created from the same respository, hence the misleading name
>>> insiade the webrev)
>>>
>>> I couldn't find rfe 6929295 in the bug database. Perhaps it's not yet
>>> publicly available?
>>
>> It usually takes a couple of days to show up in the database
>>
>>>
>>> Changes versus the last version v3.2:
>>>
>>> 1) Added a check on nativeContainer (I don't think it is necessary, but
>>> it doesn't hurt)
>>> 2) Edited the API doc for the two new methods
>>
>>
>>
>>>>
>>>> It would be really great if we manage to do only with
>>>> toLayoutSpace()/toRenderedSpace() methods
>>>> without using JComponent.inverseTransformVisibleRectangle()
>>>>
>>>> I hope you can emulate it by transforming the corner points of the
>>>> rectangle with toLayoutSpace() method and using its bounds
>>>> inside the JComponent.computeVisibleRect() method.
>>>
>>> Technically such a computation is possible. However, the
>>> JLayer.inverseTransformVisibleRectangle() does something more:
>>> it intersect the resulting rectangle with the transformed view bounds.
>>> But let's discuss that later.
>>
>> Is it possible to implement this computation right now?
>>
>> I am afraid we also need at least one simple test
>> with a custom Swing component with overridden
>> toLayoutSpace()/toRenderedSpace()
>>
>> Thanks much and sorry for the confusion!
>>
>> alexp
>>
>>>
>>>>
>>>> For the default case (no transforms, rectangles only) it will be cheap
>>>> and will simplify the usage of the new feature for the Swing
>>>> developers.
>>>>
>>>> Thanks
>>>> alexp
>>>>
>>>>>
>>>>> Hi Artem
>>>>>
>>>>>
>>>>>>
>>>>>> On 2/16/2010 6:12 PM, Piet Blok wrote:
>>>>>>> Hi Artem
>>>>>>>
>>>>>>>> Hi, Piet,
>>>>>>>>
>>>>>>>> the fix looks pretty good in general. Some small comments:
>>>>>>>>
>>>>>>>> 1. As we're about to introduce 2 new public methods into
>>>>>>>> Container, we
>>>>>>>> need to provide a description of "layout space" and "render
>>>>>>>> space". I
>>>>>>>> hope you or Alex will take care of this.
>>>>>>>
>>>>>>> What about the following descriptions?
>>>>>>>
>>>>>>> Layout space refers to user space (coordinates in the layout
>>>>>>> system).
>>>>>>> Rendered space refers to device space (coordinates on the screen).
>>>>>>> Please see (link to) AffineTransform.
>>>>>>
>>>>>> Probably, we should mention that layout coordinates are the ones used
>>>>>> by LayoutManager and other Container stuff. For example,
>>>>>> Component.getBounds() always returns layout rectangle, not rendered
>>>>>> one.
>>>>>
>>>>> Ok, good addition. I'll add that clarification.
>>>>>
>>>>>>
>>>>>>>> 2. Could toRenderedSpace() throw NoninvertibleTransformException as
>>>>>>>> well?
>>>>>>>
>>>>>>> No. toRenderedSpace() is a direct transformation with any of
>>>>>>> AffineTransform's transform() methods.
>>>>>>> This in contrast to inverse operations as used in toLayoutSpace(),
>>>>>>> like
>>>>>>> AffineTransform's createInverse() and inverseTransform() methods
>>>>>>> that
>>>>>>> may throw this exception.
>>>>>>
>>>>>> It depends on what we consider a forward transform and a reverse
>>>>>> transform :) And don't forget there may be non-affine transforms...
>>>>>
>>>>> Any transform, be it affine or non-affine is able by definition to
>>>>> transform, otherwise it's not a transform :-)
>>>>>
>>>>> Only inverse transform can be problematic. That is, when two different
>>>>> points, after transformation, result in the same point. Valid during
>>>>> transform. But impossible to do an inverse. Analogous to
>>>>> multiplying by
>>>>> zero is valid, but the operation can't be inversed.
>>>>>
>>>>>>
>>>>>>>> 3. getRenderedSpaceShift() - should we traverse containers up to
>>>>>>>> null
>>>>>>>> or up to the nativeContainer?
>>>>>>>
>>>>>>> Good point. For testing I added a test "not nativeContainer" to the
>>>>>>> null
>>>>>>> test and everything still works (in my own test suite that is far
>>>>>>> more
>>>>>>> complex than the provided jtreg test cases).
>>>>>>>
>>>>>>> getRenderedSpaceShift() is invoked from eventDispatched. It should
>>>>>>> do a
>>>>>>> traversal that is analogous to the traversal there.
>>>>>>>
>>>>>>> In general, I'm not sure about the role of "nativeContainer" and
>>>>>>> how it
>>>>>>> is used. For example, I don't know if (one or more) native
>>>>>>> containers
>>>>>>> can be present in the hierachy between a Window and the lowest child
>>>>>>> component. Or is the top Window always the native container? If
>>>>>>> this is
>>>>>>> not the case, could you depict some hierarchy example where a native
>>>>>>> container is a child somewhere in the hierarchy of a JLayer's view?
>>>>>>> Then
>>>>>>> I can do a more comprehensive test.
>>>>>>
>>>>>> nativeContainer is a basic part of LightweightDispatcher
>>>>>> machinery: it
>>>>>> is the container, always heavyweight, which is served by the
>>>>>> dispatcher. An obvious example is how all the mouse events are
>>>>>> dispatched: we (AWT) receive events for heavyweight components
>>>>>> only as
>>>>>> the underlying OS isn't aware of our lightweight Swing components.
>>>>>> When the event is dispatched to a heavyweight container, it's
>>>>>> lightweight dispatcher retargets it to a proper lightweight child.
>>>>>>
>>>>>> Given that we won't support transformations for heavyweight
>>>>>> components
>>>>>> (BTW, it should also be reflected in JavaDoc), it's enough to care
>>>>>> about nativeContainer children only.
>>>>>
>>>>>
>>>>> 1) I'll add a remark to the new public methods that they only apply to
>>>>> lightweight components.
>>>>> 2) I'll study your remarks and decide if I'll add a check on
>>>>> nativeContainer.
>>>>>
>>>>> I'll let you know if and when a version 3.2 is available.
>>>>>
>>>>> Thanks,
>>>>> Piet
>>>>>
>>>>>>
>>>>>>> Please let me know, so I can prepare a version 3.2 if needed (and
>>>>>>> add
>>>>>>> the descriptions at the same time)
>>>>>>
>>>>>> 3.2 is only required if you make any significant changes based on the
>>>>>> current discussion.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Artem
>>>>>>
>>>>>>> Thanks,
>>>>>>> Piet.
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Artem
>>>>>>>>
>>>>>>>> On 2/12/2010 10:53 AM, Piet Blok wrote:
>>>>>>>>>
>>>>>>>>> Hi Artem,
>>>>>>>>>
>>>>>>>>> The webrev for version 3.1:
>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3.1/webrev/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi, Piet,
>>>>>>>>>>
>>>>>>>>>> the 3rd version looks really great! I haven't looked to Swing
>>>>>>>>>> code
>>>>>>>>>> much, though :)
>>>>>>>>>>
>>>>>>>>>> A small suggestion is to unify getRenderedSpaceShift() and
>>>>>>>>>> getLayoutSpaceShift(), so they both accept a Component and a
>>>>>>>>>> Point to
>>>>>>>>>> translate. Could they also be static methods? It seems not, as I
>>>>>>>>>> see a
>>>>>>>>>> reference to "nativeContainer" in getLayoutSpaceShift()...
>>>>>>>>>
>>>>>>>>> I unified both methods and made them static after adding
>>>>>>>>> nativeContainer
>>>>>>>>> as a parameter to both. Their signature is now:
>>>>>>>>>
>>>>>>>>> private static Point getXXXSpaceShift(Component target, Point
>>>>>>>>> dstPoint,
>>>>>>>>> Container nativeContainer)
>>>>>>>>>
>>>>>>>>> (the nativeContainer argument is used in only one of the methods)
>>>>>>>>>
>>>>>>>>> For the swing guys: in SwingUtilities and RepaintManager, where
>>>>>>>>> iterating over the parent hierarchy, I added a check to "parent !=
>>>>>>>>> null"
>>>>>>>>> to also check "!(parent instanceof Window)".
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Piet
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Artem
>>>>>>>>>>
>>>>>>>>>> On 2/11/2010 5:25 PM, Piet Blok wrote:
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Please find a third version for the webrev here:
>>>>>>>>>>> http://www.pbjar.org/OpenJDK/6899434/version-3/webrev/
>>>>>>>>>>>
>>>>>>>>>>> AWTAccessor removed again
>>>>>>>>>>>
>>>>>>>>>>> 2 protected methods for Container: toLayoutSpace(x,y) and
>>>>>>>>>>> toRenderedSpace(x,y), overridden in JLayer.
>>>>>>>>>>>
>>>>>>>>>>> Use getContainer() in getRenderedSpaceShift(), but
>>>>>>>>>>> getParent() in
>>>>>>>>>>> getLayoutSpaceShift(). The latter because it is called from
>>>>>>>>>>> retargetMouseEvent which itself uses getParent() when finding
>>>>>>>>>>> the
>>>>>>>>>>> hierarchy translation value.
>>>>>>>>>>>
>>>>>>>>>>> Indented the try block
>>>>>>>>>>>
>>>>>>>>>>> Added some jtreg test cases, one a manual test.
>>>>>>>>>>>
>>>>>>>>>>> Please review again
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Piet
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Hi Anthony,
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Piet,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The version #2 looks very good.
>>>>>>>>>>>>
>>>>>>>>>>>> Looks, yes. Unfortunately, later I detected that it doesn't
>>>>>>>>>>>> work.
>>>>>>>>>>>> It's
>>>>>>>>>>>> missing something. Oh yes, I carried out a comprehensive manual
>>>>>>>>>>>> test
>>>>>>>>>>>> but the test setup was wrong: I tested against the version
>>>>>>>>>>>> 1! (A
>>>>>>>>>>>> jtreg
>>>>>>>>>>>> test was carried out against version 2 and was succesfull).
>>>>>>>>>>>>
>>>>>>>>>>>> I'll try to manually add a remark to that webrev to state that
>>>>>>>>>>>> it's
>>>>>>>>>>>> invalid and should not be used.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2/9/2010 4:30 PM Piet Blok wrote:
>>>>>>>>>>>>>> 1) The implementation in version 2 will be used but
>>>>>>>>>>>>>> without the
>>>>>>>>>>>>>> AWTAccessor.
>>>>>>>>>>>>>
>>>>>>>>>>>>> So that the Component.transform is moved over to the JLayer
>>>>>>>>>>>>> class,
>>>>>>>>>>>>> right? That would be great.
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Yes
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2) Container.toLayoutSpace(Point) will become protected
>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>> Container implementation does nothing.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 3) LightweightDispatcher.toLayoutSpace(MouseEvent) will
>>>>>>>>>>>>>> remain
>>>>>>>>>>>>>> private and static, but will be rewritten to use
>>>>>>>>>>>>>> Container.toLayoutSpace(Point) in a hierachy loop.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 4) LightweightDispatcher.concatenateHierarchyTransforms()
>>>>>>>>>>>>>> will of
>>>>>>>>>>>>>> course be removed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I like the proposal.
>>>>>>>>>>>>
>>>>>>>>>>>> As said, something was missing: A
>>>>>>>>>>>> Container.toRenderedSpace(point) is
>>>>>>>>>>>> needed as well. This method must return the normal transformed
>>>>>>>>>>>> point,
>>>>>>>>>>>> as opposed to toLayoutSpace() that returns the inverse
>>>>>>>>>>>> transformed
>>>>>>>>>>>> point.
>>>>>>>>>>>>
>>>>>>>>>>>> And yes, like Artem pointed out in an earlier post, this
>>>>>>>>>>>> leaves the
>>>>>>>>>>>> option open for implementers to choose for a transformation
>>>>>>>>>>>> other
>>>>>>>>>>>> than
>>>>>>>>>>>> AffineTransform. Fish eye, some sinus, whatever. (Curious to
>>>>>>>>>>>> know how
>>>>>>>>>>>> one would implement the actual rendering, but that's beside the
>>>>>>>>>>>> point).
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> A minor comment regarding the code:
>>>>>>>>>>>>>
>>>>>>>>>>>>> src/share/classes/java/awt/Container.java
>>>>>>>>>>>>>> 4875 Component parent = comp.getParent();
>>>>>>>>>>>>>
>>>>>>>>>>>>> I suggest to use the getContainer() method instead. If the
>>>>>>>>>>>>> comp
>>>>>>>>>>>>> is a
>>>>>>>>>>>>> window, the getParent() may actually return an owner of the
>>>>>>>>>>>>> window,
>>>>>>>>>>>>> which we certainly don't want to deal with.
>>>>>>>>>>>>
>>>>>>>>>>>> Aha, wasn't aware of getContainer() (package private). Very
>>>>>>>>>>>> good.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Also, please make sure you format the code according the
>>>>>>>>>>>>> guidelines:
>>>>>>>>>>>>> in Container.java the code put in the new try{} blocks must be
>>>>>>>>>>>>> correctly indented.
>>>>>>>>>>>>
>>>>>>>>>>>> This I was wondering about: should I or shouldn't I (touch code
>>>>>>>>>>>> that
>>>>>>>>>>>> is otherwise not altered). Now I know, thanks.
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otherwise looks fine. Thanks!
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Ok, I'm working on version 3. And this time actually testing
>>>>>>>>>>>> against
>>>>>>>>>>>> this same version 3! I'm still working on some more simple
>>>>>>>>>>>> jtreg
>>>>>>>>>>>> test
>>>>>>>>>>>> cases and I'll change to getContainer() and indent correctly.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Piet
>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> best regards,
>>>>>>>>>>>>> Anthony
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let me know if you agree.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Piet
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



From pavel.porvatov at sun.com  Sat Feb 27 11:27:43 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Sat, 27 Feb 2010 11:27:43 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6913758: Specification
	for	SynthViewportUI.paintBorder(...) should mention that
	this	method is never called
Message-ID: <20100227112803.1854E41A41@hg.openjdk.java.net>

Changeset: 5c03237838e1
Author:    rupashka
Date:      2010-02-27 14:26 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/5c03237838e1

6913758: Specification for SynthViewportUI.paintBorder(...) should mention that this method is never called
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/synth/SynthViewportUI.java



From pavel.porvatov at sun.com  Sat Feb 27 11:49:00 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Sat, 27 Feb 2010 11:49:00 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6918447:
	SynthToolBarUI.setBorderToXXXX() methods	don't correspond
	inherited spec. They do nothing.
Message-ID: <20100227114918.CF46341A48@hg.openjdk.java.net>

Changeset: 96205ed1b196
Author:    rupashka
Date:      2010-02-27 14:47 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/96205ed1b196

6918447: SynthToolBarUI.setBorderToXXXX() methods don't correspond inherited spec. They do nothing.
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/synth/SynthToolBarUI.java



From pavel.porvatov at sun.com  Sat Feb 27 12:10:43 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Sat, 27 Feb 2010 12:10:43 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6918861:
	SynthSliderUI.uninstallDefaults() is not	called when UI is
	uninstalled
Message-ID: <20100227121102.19F0941A4E@hg.openjdk.java.net>

Changeset: 621e921a14cd
Author:    rupashka
Date:      2010-02-27 15:09 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/621e921a14cd

6918861: SynthSliderUI.uninstallDefaults() is not called when UI is uninstalled
Reviewed-by: malenkov

! src/share/classes/javax/swing/plaf/basic/BasicSliderUI.java
! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
+ test/javax/swing/JSlider/6918861/bug6918861.java



From pavel.porvatov at sun.com  Sat Feb 27 13:04:22 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Sat, 27 Feb 2010 13:04:22 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6923305: SynthSliderUI paints the
	slider track	when the slider's "paintTrack" property is set to false
Message-ID: <20100227130440.D2D2041A5D@hg.openjdk.java.net>

Changeset: 28741de0bb4a
Author:    rupashka
Date:      2010-02-27 16:03 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/28741de0bb4a

6923305: SynthSliderUI paints the slider track when the slider's "paintTrack" property is set to false
Reviewed-by: alexp

! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java
+ test/javax/swing/JSlider/6923305/bug6923305.java



From pavel.porvatov at sun.com  Sat Feb 27 13:15:58 2010
From: pavel.porvatov at sun.com (pavel.porvatov at sun.com)
Date: Sat, 27 Feb 2010 13:15:58 +0000
Subject: <Swing Dev> hg: jdk7/swing/jdk: 6929298: The
	SynthSliderUI#calculateTickRect	method should be removed
Message-ID: <20100227131618.122DF41A61@hg.openjdk.java.net>

Changeset: 2bf137beb9bd
Author:    rupashka
Date:      2010-02-27 16:14 +0300
URL:       http://hg.openjdk.java.net/jdk7/swing/jdk/rev/2bf137beb9bd

6929298: The SynthSliderUI#calculateTickRect method should be removed
Reviewed-by: peterz

! src/share/classes/javax/swing/plaf/synth/SynthSliderUI.java