From semyon.sadetsky at oracle.com  Thu Sep  1 07:45:06 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 1 Sep 2016 10:45:06 +0300
Subject: <AWT Dev> [9] Review request 8155083: On Windows,
 usage of USER_ATTENTION_WINDOW depends on state setting order
In-Reply-To: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com>
References: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com>
Message-ID: <72cbee44-bf39-ada0-265c-818522183afe@oracle.com>

Hi Alexander,

FlashWindow() flashes window only once. Before the fix it was 3 times. 
Will it be ok for the iconified window state?

--Semyon


On 26.08.2016 05:53, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8155083/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8155083
>
> With current implementation we are showing initially iconified window 
> with SW_SHOWMINIMIZED flag, it activates the window, FlashWindowEx 
> doesn't work with active window.
> We could use SW_SHOWMINNOACTIVE instead, but there is another issue: 
> if app has more than one window it doesn't work either.
> The fix it to use FlashWindow().
>


From rajeev.chamyal at oracle.com  Thu Sep  1 08:59:44 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Thu, 1 Sep 2016 01:59:44 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57C0B745.3040601@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
Message-ID: <464e5282-0317-49eb-b03f-d937dc97af58@default>

Hello Kumar,

Can you please review the updated src/java.base/share/classes/sun/launcher/resources/launcher.properties
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/ 

Regards,
Rajeev Chamyal

-----Original Message-----
From: Philip Race 
Sent: 27 August 2016 03:10
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention

Seems fine now.
1) Please do a CCC for this
2) Please file a doc. bug so docs team can update the HTML man page and also perhaps https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html

-phil

On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
> Hello Alexandr,
>
> Please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Alexandr Scherbatiy
> Sent: 25 August 2016 22:07
> To: Rajeev Chamyal; Philip Race
> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 Unify 
> the HiDPI splash screen image naming convention
>
> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>> Hello Phil,
>>
>> Thanks for the review,
>> Please review updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>> Updated files:
>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>> s src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h
>      The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>
>     Thanks,
>     Alexandr.
>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Phil Race
>> Sent: 20 August 2016 01:47
>> To: Rajeev Chamyal
>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>> Unify the HiDPI splash screen image naming convention
>>
>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>
>> -phil.
>>
>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>> Hello Phil,
>>>
>>> Please review the updated webrev.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>
>>> Updated file
>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>> e
>>> s
>>>
>>> Added all other supported name extensions.
>>>
>>> Regards,
>>>
>>> Rajeev Chamyal
>>>
>>> *From:*Philip Race
>>> *Sent:* 19 August 2016 04:48
>>> *To:* Rajeev Chamyal
>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>> Scherbatiy
>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> Better, although it still does not document the supported set of 
>>> scale name extensions that we discussed/proposed off-line.
>>>
>>> -phil.
>>>
>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>
>>>       Hello Phil,
>>>
>>>       Thanks for the review.
>>>
>>>       Please review the updated webrev.
>>>
>>>       http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>       <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>
>>>       Updated file
>>>
>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>> e
>>> s
>>>
>>>       Regards,
>>>
>>>       Rajeev Chamyal
>>>
>>>       *From:*Phil Race
>>>       *Sent:* 16 August 2016 22:28
>>>       *To:* Alexandr Scherbatiy
>>>       *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>       <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>       *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>       Unify the HiDPI splash screen image naming convention
>>>
>>>       On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>
>>>
>>>           The fix looks good to me.
>>>
>>>           It would be better if a native speaker look at the
>>>           documentation change in the launcher.properties file.
>>>
>>>
>>>       That documentation seems to cover only *some* of the extensions we
>>>       discussed.
>>>       It ought to cite all of them if it does so at all. How else are
>>>       people supposed
>>>       to know what they can use ? Where else are you documenting it?
>>>       Perhaps the launcher "man" page should be updated too
>>>       find . -name java.1
>>>       ./src/linux/doc/man/java.1
>>>       ./src/linux/doc/man/ja/java.1
>>>       ./src/bsd/doc/man/java.1
>>>       ./src/bsd/doc/man/ja/java.1
>>>       ./src/solaris/doc/sun/man/man1/java.1
>>>       ./src/solaris/doc/sun/man/man1/ja/java.1
>>>
>>>       .. although I think there is also some HTML version maintained by
>>>       the pubs/docs team
>>>       that is not in OpenJDK - the above does not include Windows or Mac.
>>>       I don't know offhand what is recommended these days. We'll have to
>>>       find someone
>>>       who does more with the launcher to help point to where to do the
>>>       documentation.
>>>
>>>       And the doc does not really explain what is going on here. Reading
>>>       that I might
>>>       think I am supposed to pass -splash:image at 2x.ext if I want a
>>>       hi-dpi image
>>>       and that is not the idea at all, is it ?
>>>       The idea is you would still specify -splash:image.ext and the
>>>       *implementation*
>>>       will look for the most appropriate scaled image for the current
>>>       desktop.
>>>
>>>       I think we should also have a CCC cover this (somehow).
>>>
>>>       -phil.
>>>
>>>
>>>
>>>
>>>           Thanks,
>>>           Alexandr.
>>>
>>>           On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>
>>>               Hello Alexandr,
>>>
>>>               Please review the updated webrev.
>>>
>>>               
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>
>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>
>>>               Updates :
>>>
>>>               1)Updated the consition as suggested  if(*scaleFactor -
>>>               (int)*scaleFactor<  0.000001)
>>>
>>>               2)Includes the changes of
>>>
>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>
>>>               3)+        //map the splash co-ordinates as per system scale
>>>               +        splash->x /= splash->scaleFactor;
>>>               +        splash->y /= splash->scaleFactor;
>>>
>>>
>>>
>>>               This change is required only for windows and linux. As we
>>>               use absolute system resolution for centring the splash on
>>>               screen on these.
>>>
>>>               i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>               resolution) on windows and linux we use this for centring
>>>               the splash on screen. For mac scaled resolution is used
>>>               directly.
>>>
>>>               Regards,
>>>
>>>               Rajeev Chamyal
>>>
>>>               *From:*Alexander Scherbatiy
>>>               *Sent:* 11 August 2016 14:44
>>>               *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>               <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>               Bylokhov
>>>               *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>               JDK-8151787 Unify the HiDPI splash screen image naming
>>>               convention
>>>
>>>               On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>
>>>
>>>
>>>                   On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>
>>>                       Hello All,
>>>
>>>                       Please review the following webrev.
>>>
>>>                       Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>
>>>                       Webrev:
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>
>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>
>>>
>>>                       Issue: Currently different naming conventions are
>>>                       used for Hidpi image on different platforms.
>>>
>>>                       With this change the names will be unified across
>>>                       all platforms.
>>>
>>>                       For a unscaled image image.ext following naming
>>>                       convention will be followed.
>>>
>>>                       Unscaled name: image.ext
>>>
>>>                       Supported Scaled Names:
>>>
>>>                       If screen scale is integer number e.g. 2:
>>>                       image at 2x.ext<mailto:image at 2x.ext>
>>>
>>>                       If screen scale is float value like 1.25:
>>>                       image at 125pct.ext<mailto:image at 125pct.ext>
>>>
>>>
>>>                   The fix should be reviewed on the awt-dev alias.
>>>
>>>                   + if(*scaleFactor - (int)*scaleFactor<  0.000001)
>>>
>>>                   Should there be so high precision there? Could only
>>>                   percent values be compared like
>>>                    if ((*scaleFactor *100) != ((int)(*scaleFactor)) 
>>> *
>>> 100)
>>>
>>>
>>>                   +        //map the splash co-ordinates as per system scale
>>>                   +        splash->x /= splash->scaleFactor;
>>>                   +        splash->y /= splash->scaleFactor;
>>>
>>>                   It looks like the splash coordinates and sizes are
>>>                   rescaled in different places. Is it possible to do
>>>                   that in the same place? May be in
>>>                   java_awt_SplashScreen.c file getBounds() function?
>>>
>>>
>>>               src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>                      *scaleFactor = getNativeScaleFactor();
>>>
>>>               Could you also include the change which requires to add
>>>               some default output screen name to the
>>>               getNativeScaleFactor() function on Linux. There is the
>>>               discussion about that:
>>>
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.ht
>>> m
>>> l
>>>
>>>               Thanks,
>>>               Alexandr.
>>>
>>>
>>>
>>>
>>>                   Thanks,
>>>                   Alexandr.
>>>
>>>
>>>
>>>
>>>                       Regards,
>>>
>>>                       Rajeev Chamyal
>>>

From anton.tarasov at jetbrains.com  Thu Sep  1 09:51:59 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 1 Sep 2016 12:51:59 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
	skip the activation/focus events
In-Reply-To: <3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
Message-ID: <CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>

On 31 Aug 2016, at 21:04, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 30.08.16 18:18, Anton Tarasov wrote:
>>>> As I wrote in JIRA, the problem is caused by the fact that a native
>>>> window (for a modal dialog) is shown before the peer starts to show.
>>>> (This seems strange, and you can investigate the reason, I?m not aware)
>>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is
>>> called on that moment and why the "Regardless" version is used?
>> 
>> Well, I suggest a one-line fix, harmless from my point of view. And I'm
>> pointing to a problematic spot alongside. I'd love to know why modal
>> dialogs are shown that way, but I'm afraid there was a hidden reason.
> 
> I wonder how do you use this dialogs, because it is not possible to dispose or make them invisible. For example all tests should dispose all windows which were created in the test, and it seems impossible in the provided code, right(tested on latest jdk9)?

What do you mean? Ok, I simply tried to dispose it, it disappeared (well, I didn?t debug to check if it was disposed properly, but visually I see no problem). So, please clarify.

Why do I have to dispose all windows in a reg test?

Of course I tested it, on jdk9 of a version matching the date of submitting the fix.

Regards,
Anton.

> 
>>> --Semyon
>>>> The problem is thus specific to OSX.
>>>> 
>>>> Regards,
>>>> Anton.
>>>> 
>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>> 
>>>>> Hi Anton,
>>>>> 
>>>>> is it really OS X only problem? It seems on other platforms the peer
>>>>> focusability is updated in the same way.
>>>>> 
>>>>> --Semyon
>>>>> 
>>>>> 
>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Please review the fix:
>>>>>> 
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>> 
>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>> events on OSX.
>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>> earlier, in its ctor.
>>>>>> Please find more details in JIRA.
>>>>>> 
>>>>>> Thanks,
>>>>>> Anton.
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.


From alexander.zvegintsev at oracle.com  Thu Sep  1 11:26:03 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 1 Sep 2016 14:26:03 +0300
Subject: <AWT Dev> [9] Review request 8155083: On Windows,
 usage of USER_ATTENTION_WINDOW depends on state setting order
In-Reply-To: <72cbee44-bf39-ada0-265c-818522183afe@oracle.com>
References: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com>
	<72cbee44-bf39-ada0-265c-818522183afe@oracle.com>
Message-ID: <44f8eda3-384c-80f7-48db-85bc904c4066@oracle.com>

Hi Semyon,

This is intended. Sure, it will(the issue is filed against this test 
case, so it is the first test case I've checked).


On 9/1/16 10:45 AM, Semyon Sadetsky wrote:
> Hi Alexander,
>
> FlashWindow() flashes window only once. Before the fix it was 3 times. 
> Will it be ok for the iconified window state?
>
> --Semyon
>
>
> On 26.08.2016 05:53, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8155083/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8155083
>>
>> With current implementation we are showing initially iconified window 
>> with SW_SHOWMINIMIZED flag, it activates the window, FlashWindowEx 
>> doesn't work with active window.
>> We could use SW_SHOWMINNOACTIVE instead, but there is another issue: 
>> if app has more than one window it doesn't work either.
>> The fix it to use FlashWindow().
>>
>

-- 
Thanks,
Alexander.


From semyon.sadetsky at oracle.com  Thu Sep  1 11:29:53 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 1 Sep 2016 14:29:53 +0300
Subject: <AWT Dev> [9] Review request 8155083: On Windows,
 usage of USER_ATTENTION_WINDOW depends on state setting order
In-Reply-To: <44f8eda3-384c-80f7-48db-85bc904c4066@oracle.com>
References: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com>
	<72cbee44-bf39-ada0-265c-818522183afe@oracle.com>
	<44f8eda3-384c-80f7-48db-85bc904c4066@oracle.com>
Message-ID: <a194e46f-fc63-3bd3-8c17-1050f546d7a1@oracle.com>

I thought that the native Windows behavior is flashing it several times. 
But probably it is not true.

Then the fix looks good.

--Semyon


On 01.09.2016 14:26, Alexander Zvegintsev wrote:
> Hi Semyon,
>
> This is intended. Sure, it will(the issue is filed against this test 
> case, so it is the first test case I've checked).
>
>
> On 9/1/16 10:45 AM, Semyon Sadetsky wrote:
>> Hi Alexander,
>>
>> FlashWindow() flashes window only once. Before the fix it was 3 
>> times. Will it be ok for the iconified window state?
>>
>> --Semyon
>>
>>
>> On 26.08.2016 05:53, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8155083/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8155083
>>>
>>> With current implementation we are showing initially iconified 
>>> window with SW_SHOWMINIMIZED flag, it activates the window, 
>>> FlashWindowEx doesn't work with active window.
>>> We could use SW_SHOWMINNOACTIVE instead, but there is another issue: 
>>> if app has more than one window it doesn't work either.
>>> The fix it to use FlashWindow().
>>>
>>
>


From Sergey.Bylokhov at oracle.com  Thu Sep  1 11:31:53 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Sep 2016 14:31:53 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
 skip the activation/focus events
In-Reply-To: <CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
	<CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
Message-ID: <765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>

On 01.09.16 12:51, Anton Tarasov wrote:
> On 31 Aug 2016, at 21:04, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> On 30.08.16 18:18, Anton Tarasov wrote:
>>>>> As I wrote in JIRA, the problem is caused by the fact that a native
>>>>> window (for a modal dialog) is shown before the peer starts to show.
>>>>> (This seems strange, and you can investigate the reason, I?m not aware)
>>>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is
>>>> called on that moment and why the "Regardless" version is used?
>>>
>>> Well, I suggest a one-line fix, harmless from my point of view. And I'm
>>> pointing to a problematic spot alongside. I'd love to know why modal
>>> dialogs are shown that way, but I'm afraid there was a hidden reason.
>>
>> I wonder how do you use this dialogs, because it is not possible to dispose or make them invisible. For example all tests should dispose all windows which were created in the test, and it seems impossible in the provided code, right(tested on latest jdk9)?
>
> What do you mean? Ok, I simply tried to dispose it, it disappeared (well, I didn?t debug to check if it was disposed properly, but visually I see no problem). So, please clarify.

I just check on the latest jdk9 and jdk8u101, I add these lines to the test:
   f.setVisible(true);
   d.setVisible(true);
+ f.dispose();
+ d.dispose();

but both frames are still visible. This is why I wonder, how did you 
close it in the app.

>
> Why do I have to dispose all windows in a reg test?
>
> Of course I tested it, on jdk9 of a version matching the date of submitting the fix.
>
> Regards,
> Anton.
>
>>
>>>> --Semyon
>>>>> The problem is thus specific to OSX.
>>>>>
>>>>> Regards,
>>>>> Anton.
>>>>>
>>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>
>>>>>> Hi Anton,
>>>>>>
>>>>>> is it really OS X only problem? It seems on other platforms the peer
>>>>>> focusability is updated in the same way.
>>>>>>
>>>>>> --Semyon
>>>>>>
>>>>>>
>>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the fix:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>>>
>>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>>> events on OSX.
>>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>>> earlier, in its ctor.
>>>>>>> Please find more details in JIRA.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Sep  1 13:41:42 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 1 Sep 2016 16:41:42 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
Message-ID: <2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>



On 31.08.2016 21:18, Sergey Bylokhov wrote:
> On 31.08.16 17:18, Semyon Sadetsky wrote:
>> Toolkit.getDefaultToolkit().getScreenSize()
>>
>> was replaced by
>>
>> graphicsConfig.getBounds();
>>
>> that returns a particular screen area which is not the same as the joint
>> screen area in case of Xinerama multi-monitor configuration.
>
> Can you please clarify what is the difference between two methods in 
> this bug? Toolkit.getScreenSize() is related to the main screen 
> only(defaul gc config), but gc.getBounds() is related to appropriate 
> screen(and take scale factor of those screen into account). In case of 
> xinerama we should have two GC which should have each own scales.
It was explained above already: they return different things. 
Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds() 
returns particular screen bounds.

From kumar.x.srinivasan at oracle.com  Thu Sep  1 13:47:19 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Thu, 01 Sep 2016 06:47:19 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <464e5282-0317-49eb-b03f-d937dc97af58@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
Message-ID: <57C83167.6080108@oracle.com>


Hello Rajeev,

IMHO, this really belongs here:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java

and here:

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

If you can reduce the words in the launcher, it would be good, also
please make sure the lines do not exceed 80 chars ie. the output of
java -help.


Kumar



> Hello Kumar,
>
> Can you please review the updated src/java.base/share/classes/sun/launcher/resources/launcher.properties
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Philip Race
> Sent: 27 August 2016 03:10
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
> Seems fine now.
> 1) Please do a CCC for this
> 2) Please file a doc. bug so docs team can update the HTML man page and also perhaps https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html
>
> -phil
>
> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> Please review the updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexandr Scherbatiy
>> Sent: 25 August 2016 22:07
>> To: Rajeev Chamyal; Philip Race
>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 Unify
>> the HiDPI splash screen image naming convention
>>
>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>> Hello Phil,
>>>
>>> Thanks for the review,
>>> Please review updated webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>> Updated files:
>>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>>> s src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h
>>       The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>
>>      Thanks,
>>      Alexandr.
>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Phil Race
>>> Sent: 20 August 2016 01:47
>>> To: Rajeev Chamyal
>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>
>>> -phil.
>>>
>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>> Hello Phil,
>>>>
>>>> Please review the updated webrev.
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>
>>>> Updated file
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>>> e
>>>> s
>>>>
>>>> Added all other supported name extensions.
>>>>
>>>> Regards,
>>>>
>>>> Rajeev Chamyal
>>>>
>>>> *From:*Philip Race
>>>> *Sent:* 19 August 2016 04:48
>>>> *To:* Rajeev Chamyal
>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>> Scherbatiy
>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> Better, although it still does not document the supported set of
>>>> scale name extensions that we discussed/proposed off-line.
>>>>
>>>> -phil.
>>>>
>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>
>>>>        Hello Phil,
>>>>
>>>>        Thanks for the review.
>>>>
>>>>        Please review the updated webrev.
>>>>
>>>>        http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>        <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>
>>>>        Updated file
>>>>
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>>> e
>>>> s
>>>>
>>>>        Regards,
>>>>
>>>>        Rajeev Chamyal
>>>>
>>>>        *From:*Phil Race
>>>>        *Sent:* 16 August 2016 22:28
>>>>        *To:* Alexandr Scherbatiy
>>>>        *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>        <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>        *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>        Unify the HiDPI splash screen image naming convention
>>>>
>>>>        On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>
>>>>
>>>>            The fix looks good to me.
>>>>
>>>>            It would be better if a native speaker look at the
>>>>            documentation change in the launcher.properties file.
>>>>
>>>>
>>>>        That documentation seems to cover only *some* of the extensions we
>>>>        discussed.
>>>>        It ought to cite all of them if it does so at all. How else are
>>>>        people supposed
>>>>        to know what they can use ? Where else are you documenting it?
>>>>        Perhaps the launcher "man" page should be updated too
>>>>        find . -name java.1
>>>>        ./src/linux/doc/man/java.1
>>>>        ./src/linux/doc/man/ja/java.1
>>>>        ./src/bsd/doc/man/java.1
>>>>        ./src/bsd/doc/man/ja/java.1
>>>>        ./src/solaris/doc/sun/man/man1/java.1
>>>>        ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>
>>>>        .. although I think there is also some HTML version maintained by
>>>>        the pubs/docs team
>>>>        that is not in OpenJDK - the above does not include Windows or Mac.
>>>>        I don't know offhand what is recommended these days. We'll have to
>>>>        find someone
>>>>        who does more with the launcher to help point to where to do the
>>>>        documentation.
>>>>
>>>>        And the doc does not really explain what is going on here. Reading
>>>>        that I might
>>>>        think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>        hi-dpi image
>>>>        and that is not the idea at all, is it ?
>>>>        The idea is you would still specify -splash:image.ext and the
>>>>        *implementation*
>>>>        will look for the most appropriate scaled image for the current
>>>>        desktop.
>>>>
>>>>        I think we should also have a CCC cover this (somehow).
>>>>
>>>>        -phil.
>>>>
>>>>
>>>>
>>>>
>>>>            Thanks,
>>>>            Alexandr.
>>>>
>>>>            On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>
>>>>                Hello Alexandr,
>>>>
>>>>                Please review the updated webrev.
>>>>
>>>>                
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>
>>>>                Updates :
>>>>
>>>>                1)Updated the consition as suggested  if(*scaleFactor -
>>>>                (int)*scaleFactor<  0.000001)
>>>>
>>>>                2)Includes the changes of
>>>>
>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>
>>>>                3)+        //map the splash co-ordinates as per system scale
>>>>                +        splash->x /= splash->scaleFactor;
>>>>                +        splash->y /= splash->scaleFactor;
>>>>
>>>>
>>>>
>>>>                This change is required only for windows and linux. As we
>>>>                use absolute system resolution for centring the splash on
>>>>                screen on these.
>>>>
>>>>                i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>                resolution) on windows and linux we use this for centring
>>>>                the splash on screen. For mac scaled resolution is used
>>>>                directly.
>>>>
>>>>                Regards,
>>>>
>>>>                Rajeev Chamyal
>>>>
>>>>                *From:*Alexander Scherbatiy
>>>>                *Sent:* 11 August 2016 14:44
>>>>                *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>                <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>                Bylokhov
>>>>                *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>                JDK-8151787 Unify the HiDPI splash screen image naming
>>>>                convention
>>>>
>>>>                On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>
>>>>
>>>>
>>>>                    On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>
>>>>                        Hello All,
>>>>
>>>>                        Please review the following webrev.
>>>>
>>>>                        Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>
>>>>                        Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>
>>>>
>>>>                        Issue: Currently different naming conventions are
>>>>                        used for Hidpi image on different platforms.
>>>>
>>>>                        With this change the names will be unified across
>>>>                        all platforms.
>>>>
>>>>                        For a unscaled image image.ext following naming
>>>>                        convention will be followed.
>>>>
>>>>                        Unscaled name: image.ext
>>>>
>>>>                        Supported Scaled Names:
>>>>
>>>>                        If screen scale is integer number e.g. 2:
>>>>                        image at 2x.ext<mailto:image at 2x.ext>
>>>>
>>>>                        If screen scale is float value like 1.25:
>>>>                        image at 125pct.ext<mailto:image at 125pct.ext>
>>>>
>>>>
>>>>                    The fix should be reviewed on the awt-dev alias.
>>>>
>>>>                    + if(*scaleFactor - (int)*scaleFactor<  0.000001)
>>>>
>>>>                    Should there be so high precision there? Could only
>>>>                    percent values be compared like
>>>>                     if ((*scaleFactor *100) != ((int)(*scaleFactor))
>>>> *
>>>> 100)
>>>>
>>>>
>>>>                    +        //map the splash co-ordinates as per system scale
>>>>                    +        splash->x /= splash->scaleFactor;
>>>>                    +        splash->y /= splash->scaleFactor;
>>>>
>>>>                    It looks like the splash coordinates and sizes are
>>>>                    rescaled in different places. Is it possible to do
>>>>                    that in the same place? May be in
>>>>                    java_awt_SplashScreen.c file getBounds() function?
>>>>
>>>>
>>>>                src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>                       *scaleFactor = getNativeScaleFactor();
>>>>
>>>>                Could you also include the change which requires to add
>>>>                some default output screen name to the
>>>>                getNativeScaleFactor() function on Linux. There is the
>>>>                discussion about that:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.ht
>>>> m
>>>> l
>>>>
>>>>                Thanks,
>>>>                Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>                    Thanks,
>>>>                    Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>                        Regards,
>>>>
>>>>                        Rajeev Chamyal
>>>>


From anton.tarasov at jetbrains.com  Thu Sep  1 14:22:13 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 1 Sep 2016 17:22:13 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
	skip the activation/focus events
In-Reply-To: <765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
	<CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
	<765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>
Message-ID: <2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>

On 01 Sep 2016, at 14:31, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 01.09.16 12:51, Anton Tarasov wrote:
>> On 31 Aug 2016, at 21:04, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>> 
>>> On 30.08.16 18:18, Anton Tarasov wrote:
>>>>>> As I wrote in JIRA, the problem is caused by the fact that a native
>>>>>> window (for a modal dialog) is shown before the peer starts to show.
>>>>>> (This seems strange, and you can investigate the reason, I?m not aware)
>>>>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is
>>>>> called on that moment and why the "Regardless" version is used?
>>>> 
>>>> Well, I suggest a one-line fix, harmless from my point of view. And I'm
>>>> pointing to a problematic spot alongside. I'd love to know why modal
>>>> dialogs are shown that way, but I'm afraid there was a hidden reason.
>>> 
>>> I wonder how do you use this dialogs, because it is not possible to dispose or make them invisible. For example all tests should dispose all windows which were created in the test, and it seems impossible in the provided code, right(tested on latest jdk9)?
>> 
>> What do you mean? Ok, I simply tried to dispose it, it disappeared (well, I didn?t debug to check if it was disposed properly, but visually I see no problem). So, please clarify.
> 
> I just check on the latest jdk9 and jdk8u101, I add these lines to the test:
>  f.setVisible(true);
>  d.setVisible(true);
> + f.dispose();
> + d.dispose();
> 
> but both frames are still visible. This is why I wonder, how did you close it in the app.

You probably missed the fact the dialog is modal.

Anton.

> 
>> 
>> Why do I have to dispose all windows in a reg test?
>> 
>> Of course I tested it, on jdk9 of a version matching the date of submitting the fix.
>> 
>> Regards,
>> Anton.
>> 
>>> 
>>>>> --Semyon
>>>>>> The problem is thus specific to OSX.
>>>>>> 
>>>>>> Regards,
>>>>>> Anton.
>>>>>> 
>>>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>> 
>>>>>>> Hi Anton,
>>>>>>> 
>>>>>>> is it really OS X only problem? It seems on other platforms the peer
>>>>>>> focusability is updated in the same way.
>>>>>>> 
>>>>>>> --Semyon
>>>>>>> 
>>>>>>> 
>>>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Please review the fix:
>>>>>>>> 
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>>>> 
>>>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>>>> events on OSX.
>>>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>>>> earlier, in its ctor.
>>>>>>>> Please find more details in JIRA.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Sep  1 14:56:36 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 1 Sep 2016 17:56:36 +0300
Subject: <AWT Dev> [9] Review request for 8050478: [macosx] Cursor not
 updating correctly after closing a modal dialog
In-Reply-To: <9BEECA1C-6092-429A-9372-8AE63BAB7343@oracle.com>
References: <57BC2514.8060906@oracle.com>
	<948f82df-ff51-89ba-177e-c21f90fb6bfc@oracle.com>
	<59902D62-5BA5-4072-BB02-D7E11DF01E74@oracle.com>
	<d83ce9b9-f499-c822-18dc-e99e4779dbd2@oracle.com>
	<BB315732-6F1E-4547-9EA9-17D1961F6EE8@oracle.com>
	<df0bd70b-2f76-1850-dfe9-f0728f3f458f@oracle.com>
	<9BEECA1C-6092-429A-9372-8AE63BAB7343@oracle.com>
Message-ID: <3afed1ed-66f3-170a-d87e-294cdd3f26cb@oracle.com>


The fix looks good to me.

Thanks,
Alexandr.

On 8/30/2016 11:20 AM, Dmitry Markov wrote:
> Thank you very much, Sergey!
> Looking for a second +1 from someone else.
>
> Thanks,
> Dmitry
>> On 29 Aug 2016, at 18:53, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>
>> Looks fine.
>>
>> On 25.08.16 13:53, Dmitry Markov wrote:
>>> Hi Sergey,
>>>
>>> I have updated the fix based on your suggestion, (i.e. add a new
>>> method). Please find a new version here:
>>> http://cr.openjdk.java.net/~dmarkov/8050478/webrev.01/
>>>
>>> Thanks,
>>> Dmitry
>>>> On 24 Aug 2016, at 18:27, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
>>>> <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>
>>>> Then I suggest to add a new method which will generate the EXIT before
>>>> disable the window(I think it is better way?), or rename the current
>>>> method since after the fix this is not a simple nativeSetEnabled() method.
>>>>
>>>> On 24.08.16 11:03, Dmitry Markov wrote:
>>>>> Hi Sergey,
>>>>>
>>>>> Thank you for the review.
>>>>>
>>>>> Actually the event is generated when the dialog is displayed, but it
>>>>> is discarded in deliverJavaMouseEvent() function (see AWTView.m)
>>>>> since the window is already disabled. When we are going to show a
>>>>> modal dialog we disable/block previously displayed windows via
>>>>> setModalBlocked() method. So we have to generate and send MouseExited
>>>>> event to the window before it is disabled/blocked by the modal dialog.
>>>>>
>>>>> Thanks,
>>>>> Dmitry
>>>>>> On 23 Aug 2016, at 22:01, Sergey Bylokhov
>>>>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>>>>>
>>>>>> Why this event is not generated by the
>>>>>> nativeSynthesizeMouseEnteredExitedEvents() when we show the dialog?
>>>>>>
>>>>>> On 23.08.16 13:27, dmitry markov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Could you review a fix for jdk9, please?
>>>>>>>
>>>>>>>   bug: https://bugs.openjdk.java.net/browse/JDK-8050478
>>>>>>>   webrev: http://cr.openjdk.java.net/~dmarkov/8050478/webrev.00/
>>>>>>>
>>>>>>> Problem description:
>>>>>>> Cursor is not updated correctly after closing a modal dialog. The root
>>>>>>> cause of the issue is lack of a mouse exit event during displaying of
>>>>>>> the modal dialog.
>>>>>>>
>>>>>>> Fix:
>>>>>>> It is necessary to generate MouseExited event for the window which is
>>>>>>> going to be blocked by the modal dialog.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Dmitry
>>>>>>
>>>>>> --
>>>>>> Best regards, Sergey.
>>>>
>>>> --
>>>> Best regards, Sergey.
>>
>> -- 
>> Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Thu Sep  1 15:32:28 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Thu, 1 Sep 2016 18:32:28 +0300
Subject: <AWT Dev> [9] Review request for 8163100: [hidpi] Linux:
 display-wise scaling factor issues
In-Reply-To: <c3ef80fe-930e-1476-76dd-8c8116dd8350@oracle.com>
References: <d92bb458-c2a2-1e6f-6206-36189834b09f@oracle.com>
	<84d50f83-1819-8806-193a-77a9f273e308@oracle.com>
	<5e110aef-967e-969c-fee2-f4aa4f922846@oracle.com>
	<c3ef80fe-930e-1476-76dd-8c8116dd8350@oracle.com>
Message-ID: <b8f768ea-1fcc-2b87-4ccd-5a2c0f26e20c@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 8/31/2016 2:07 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 31.08.16 11:11, Semyon Sadetsky wrote:
>> On 8/30/2016 11:57 PM, Sergey Bylokhov wrote:
>>
>>> Why in X11GraphicsDevice.java we cannot call initScaleFactor()
>>> directly without isUIScaleEnabled() check like we do on win/osx? The
>>> same check is made inside this method.
>> don't see why this check is bad, but since it is not very necessary I
>> have removed it:
>> http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.01/
>>>
>>> On 30.08.16 16:26, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8163100
>>>>
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8163100/webrev.00/
>>>>
>>>> - UI scale listener is added to track system scale changes in Java.
>>>>
>>>> - Support for individual monitor scale is removed in case of Xinerama
>>>> because it is not supported in native apps.
>>>>
>>>> - Bug with display name comparison during reading of system scale
>>>> settings is fixed.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>
>>>
>>
>
>


From iris.clark at oracle.com  Thu Sep  1 20:32:02 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 1 Sep 2016 13:32:02 -0700 (PDT)
Subject: <AWT Dev> RFR: XXS: (doc) Toolkit.isDynamicLayoutActive(): orphan
 '0' in first sentence
Message-ID: <950088a2-cbe2-4242-94db-d35797673da8@default>

Hi.

Please review the following one character change to remove an unnecessary ')'
in the first sentence of Toolkit.isDynamicLayoutActive().  The matching '(' was
removed during resolution of JDK-8027234 (build 120) which clarified the
specification of this method.

    8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan ')' in first sentence
    https://bugs.openjdk.java.net/browse/JDK-8165269


diff -r 14918637b76e src/java.desktop/share/classes/java/awt/Toolkit.java
--- a/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 16:18:14 2016 +0530
+++ b/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 13:10:03 2016 -0700
@@ -208,7 +208,7 @@

     /**
      * Returns whether dynamic layout of Containers on resize is currently
-     * enabled on the underlying operating system and/or window manager). If the
+     * enabled on the underlying operating system and/or window manager. If the
      * platform supports it, {@code setDynamicLayout(boolean)} may be used to
      * programmatically enable or disable platform dynamic layout. Regardless of
      * whether that toggling is supported, or whether {@code true} or {@code

Thanks,
Iris

From iris.clark at oracle.com  Thu Sep  1 20:37:14 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 1 Sep 2016 13:37:14 -0700 (PDT)
Subject: <AWT Dev> RFR: XXS: (doc) Toolkit.isDynamicLayoutActive():
 orphan '0' in first sentence
In-Reply-To: <950088a2-cbe2-4242-94db-d35797673da8@default>
References: <950088a2-cbe2-4242-94db-d35797673da8@default>
Message-ID: <dc9ab8c6-24c2-4bf4-a5c3-0c3c011be72e@default>

Problematic cut-and-paste coupled with misbehaving mail client.

Let me generate the webrev to be crystal clear.

Thanks,
iris

-----Original Message-----
From: Iris Clark 
Sent: Thursday, September 01, 2016 1:32 PM
To: aw >> OpenJDK awt-dev
Cc: Iris Clark
Subject: RFR: XXS: (doc) Toolkit.isDynamicLayoutActive(): orphan '0' in first sentence

Hi.

Please review the following one character change to remove an unnecessary ')'
in the first sentence of Toolkit.isDynamicLayoutActive().  The matching '(' was removed during resolution of JDK-8027234 (build 120) which clarified the specification of this method.

    8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan ')' in first sentence
    https://bugs.openjdk.java.net/browse/JDK-8165269

diff -r 14918637b76e src/java.desktop/share/classes/java/awt/Toolkit.java
--- a/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 16:18:14 2016 +0530
+++ b/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 13:10:03 2016 -0700
@@ -208,7 +208,7 @@

     /**
      * Returns whether dynamic layout of Containers on resize is currently
-     * enabled on the underlying operating system and/or window manager). If the
+     * enabled on the underlying operating system and/or window manager. If the
      * platform supports it, {@code setDynamicLayout(boolean)} may be used to
      * programmatically enable or disable platform dynamic layout. Regardless of
      * whether that toggling is supported, or whether {@code true} or {@code

Thanks,
Iris

From iris.clark at oracle.com  Thu Sep  1 20:46:30 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Thu, 1 Sep 2016 13:46:30 -0700 (PDT)
Subject: <AWT Dev> RFR (XXS) 8165269: (doc) Toolkit.isDynamicLayoutActive():
 orphan '0' in first sentence
Message-ID: <ad4d9d3c-3a5a-4bb4-b1b0-45b28a3918b9@default>

Hi.

Let's try this again.

Please review the following one character change to remove an unnecessary ')'
in the first sentence of Toolkit.isDynamicLayoutActive().  The matching '(' was 
removed during resolution of JDK-8027234 (build 120) which clarified the 
specification of this method.

Bug:

    8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan ')' in first sentence
    https://bugs.openjdk.java.net/browse/JDK-8165269

patch (from webrev):

    http://cr.openjdk.java.net/~iris/8165269/webrev/jdk.patch

Thanks,
iris

diff -r 14918637b76e src/java.desktop/share/classes/java/awt/Toolkit.java
--- a/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 16:18:14 2016 +0530
+++ b/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 13:10:03 2016 -0700
@@ -208,7 +208,7 @@

     /**
      * Returns whether dynamic layout of Containers on resize is currently
-     * enabled on the underlying operating system and/or window manager). If the
+     * enabled on the underlying operating system and/or window manager. If the
      * platform supports it, {@code setDynamicLayout(boolean)} may be used to
      * programmatically enable or disable platform dynamic layout. Regardless of
      * whether that toggling is supported, or whether {@code true} or {@code

From rajeev.chamyal at oracle.com  Fri Sep  2 07:23:37 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Fri, 2 Sep 2016 00:23:37 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57C83167.6080108@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
Message-ID: <f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>

Hello Kumar,

I have further updated launcher.properties.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/

For documentation update I have already raise a bug.
https://bugs.openjdk.java.net/browse/JDK-8165009

Regards,
Rajeev Chamyal

-----Original Message-----
From: Kumar Srinivasan 
Sent: 01 September 2016 19:17
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; Philip Race
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention


Hello Rajeev,

IMHO, this really belongs here:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java

and here:

https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html

If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.


Kumar



> Hello Kumar,
>
> Can you please review the updated 
> src/java.base/share/classes/sun/launcher/resources/launcher.properties
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Philip Race
> Sent: 27 August 2016 03:10
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify 
> the HiDPI splash screen image naming convention
>
> Seems fine now.
> 1) Please do a CCC for this
> 2) Please file a doc. bug so docs team can update the HTML man page 
> and also perhaps 
> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html
>
> -phil
>
> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>> Hello Alexandr,
>>
>> Please review the updated webrev.
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Alexandr Scherbatiy
>> Sent: 25 August 2016 22:07
>> To: Rajeev Chamyal; Philip Race
>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>> Unify the HiDPI splash screen image naming convention
>>
>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>> Hello Phil,
>>>
>>> Thanks for the review,
>>> Please review updated webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>> Updated files:
>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>> e s 
>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h
>>       The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>
>>      Thanks,
>>      Alexandr.
>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Phil Race
>>> Sent: 20 August 2016 01:47
>>> To: Rajeev Chamyal
>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>
>>> -phil.
>>>
>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>> Hello Phil,
>>>>
>>>> Please review the updated webrev.
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>
>>>> Updated file
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>> i
>>>> e
>>>> s
>>>>
>>>> Added all other supported name extensions.
>>>>
>>>> Regards,
>>>>
>>>> Rajeev Chamyal
>>>>
>>>> *From:*Philip Race
>>>> *Sent:* 19 August 2016 04:48
>>>> *To:* Rajeev Chamyal
>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>> Scherbatiy
>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> Better, although it still does not document the supported set of 
>>>> scale name extensions that we discussed/proposed off-line.
>>>>
>>>> -phil.
>>>>
>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>
>>>>        Hello Phil,
>>>>
>>>>        Thanks for the review.
>>>>
>>>>        Please review the updated webrev.
>>>>
>>>>        http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>        <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>
>>>>        Updated file
>>>>
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>> i
>>>> e
>>>> s
>>>>
>>>>        Regards,
>>>>
>>>>        Rajeev Chamyal
>>>>
>>>>        *From:*Phil Race
>>>>        *Sent:* 16 August 2016 22:28
>>>>        *To:* Alexandr Scherbatiy
>>>>        *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>        <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>        *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>        Unify the HiDPI splash screen image naming convention
>>>>
>>>>        On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>
>>>>
>>>>            The fix looks good to me.
>>>>
>>>>            It would be better if a native speaker look at the
>>>>            documentation change in the launcher.properties file.
>>>>
>>>>
>>>>        That documentation seems to cover only *some* of the extensions we
>>>>        discussed.
>>>>        It ought to cite all of them if it does so at all. How else are
>>>>        people supposed
>>>>        to know what they can use ? Where else are you documenting it?
>>>>        Perhaps the launcher "man" page should be updated too
>>>>        find . -name java.1
>>>>        ./src/linux/doc/man/java.1
>>>>        ./src/linux/doc/man/ja/java.1
>>>>        ./src/bsd/doc/man/java.1
>>>>        ./src/bsd/doc/man/ja/java.1
>>>>        ./src/solaris/doc/sun/man/man1/java.1
>>>>        ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>
>>>>        .. although I think there is also some HTML version maintained by
>>>>        the pubs/docs team
>>>>        that is not in OpenJDK - the above does not include Windows or Mac.
>>>>        I don't know offhand what is recommended these days. We'll have to
>>>>        find someone
>>>>        who does more with the launcher to help point to where to do the
>>>>        documentation.
>>>>
>>>>        And the doc does not really explain what is going on here. Reading
>>>>        that I might
>>>>        think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>        hi-dpi image
>>>>        and that is not the idea at all, is it ?
>>>>        The idea is you would still specify -splash:image.ext and the
>>>>        *implementation*
>>>>        will look for the most appropriate scaled image for the current
>>>>        desktop.
>>>>
>>>>        I think we should also have a CCC cover this (somehow).
>>>>
>>>>        -phil.
>>>>
>>>>
>>>>
>>>>
>>>>            Thanks,
>>>>            Alexandr.
>>>>
>>>>            On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>
>>>>                Hello Alexandr,
>>>>
>>>>                Please review the updated webrev.
>>>>
>>>>                
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>
>>>>                Updates :
>>>>
>>>>                1)Updated the consition as suggested  if(*scaleFactor -
>>>>                (int)*scaleFactor<  0.000001)
>>>>
>>>>                2)Includes the changes of
>>>>
>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>
>>>>                3)+        //map the splash co-ordinates as per system scale
>>>>                +        splash->x /= splash->scaleFactor;
>>>>                +        splash->y /= splash->scaleFactor;
>>>>
>>>>
>>>>
>>>>                This change is required only for windows and linux. As we
>>>>                use absolute system resolution for centring the splash on
>>>>                screen on these.
>>>>
>>>>                i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>                resolution) on windows and linux we use this for centring
>>>>                the splash on screen. For mac scaled resolution is used
>>>>                directly.
>>>>
>>>>                Regards,
>>>>
>>>>                Rajeev Chamyal
>>>>
>>>>                *From:*Alexander Scherbatiy
>>>>                *Sent:* 11 August 2016 14:44
>>>>                *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>                <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>                Bylokhov
>>>>                *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>                JDK-8151787 Unify the HiDPI splash screen image naming
>>>>                convention
>>>>
>>>>                On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>
>>>>
>>>>
>>>>                    On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>
>>>>                        Hello All,
>>>>
>>>>                        Please review the following webrev.
>>>>
>>>>                        Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>
>>>>                        Webrev:
>>>>
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>
>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>
>>>>
>>>>                        Issue: Currently different naming conventions are
>>>>                        used for Hidpi image on different platforms.
>>>>
>>>>                        With this change the names will be unified across
>>>>                        all platforms.
>>>>
>>>>                        For a unscaled image image.ext following naming
>>>>                        convention will be followed.
>>>>
>>>>                        Unscaled name: image.ext
>>>>
>>>>                        Supported Scaled Names:
>>>>
>>>>                        If screen scale is integer number e.g. 2:
>>>>                        image at 2x.ext<mailto:image at 2x.ext>
>>>>
>>>>                        If screen scale is float value like 1.25:
>>>>                        image at 125pct.ext<mailto:image at 125pct.ext>
>>>>
>>>>
>>>>                    The fix should be reviewed on the awt-dev alias.
>>>>
>>>>                    + if(*scaleFactor - (int)*scaleFactor<  
>>>> 0.000001)
>>>>
>>>>                    Should there be so high precision there? Could only
>>>>                    percent values be compared like
>>>>                     if ((*scaleFactor *100) != 
>>>> ((int)(*scaleFactor))
>>>> *
>>>> 100)
>>>>
>>>>
>>>>                    +        //map the splash co-ordinates as per system scale
>>>>                    +        splash->x /= splash->scaleFactor;
>>>>                    +        splash->y /= splash->scaleFactor;
>>>>
>>>>                    It looks like the splash coordinates and sizes are
>>>>                    rescaled in different places. Is it possible to do
>>>>                    that in the same place? May be in
>>>>                    java_awt_SplashScreen.c file getBounds() function?
>>>>
>>>>
>>>>                src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>                       *scaleFactor = getNativeScaleFactor();
>>>>
>>>>                Could you also include the change which requires to add
>>>>                some default output screen name to the
>>>>                getNativeScaleFactor() function on Linux. There is the
>>>>                discussion about that:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.h
>>>> t
>>>> m
>>>> l
>>>>
>>>>                Thanks,
>>>>                Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>                    Thanks,
>>>>                    Alexandr.
>>>>
>>>>
>>>>
>>>>
>>>>                        Regards,
>>>>
>>>>                        Rajeev Chamyal
>>>>


From alexandr.scherbatiy at oracle.com  Fri Sep  2 09:52:05 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 2 Sep 2016 12:52:05 +0300
Subject: <AWT Dev> RFR (XXS) 8165269: (doc)
 Toolkit.isDynamicLayoutActive(): orphan '0' in first sentence
In-Reply-To: <ad4d9d3c-3a5a-4bb4-b1b0-45b28a3918b9@default>
References: <ad4d9d3c-3a5a-4bb4-b1b0-45b28a3918b9@default>
Message-ID: <57d00838-fcf7-e022-acda-f55e4d8ef2c0@oracle.com>


   The fix looks good to me.

   Thanks,
   Alexandr.

On 9/1/2016 11:46 PM, Iris Clark wrote:
> Hi.
>
> Let's try this again.
>
> Please review the following one character change to remove an unnecessary ')'
> in the first sentence of Toolkit.isDynamicLayoutActive().  The matching '(' was
> removed during resolution of JDK-8027234 (build 120) which clarified the
> specification of this method.
>
> Bug:
>
>      8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan ')' in first sentence
>      https://bugs.openjdk.java.net/browse/JDK-8165269
>
> patch (from webrev):
>
>      http://cr.openjdk.java.net/~iris/8165269/webrev/jdk.patch
>
> Thanks,
> iris
>
> diff -r 14918637b76e src/java.desktop/share/classes/java/awt/Toolkit.java
> --- a/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 16:18:14 2016 +0530
> +++ b/src/java.desktop/share/classes/java/awt/Toolkit.java      Thu Sep 01 13:10:03 2016 -0700
> @@ -208,7 +208,7 @@
>
>       /**
>        * Returns whether dynamic layout of Containers on resize is currently
> -     * enabled on the underlying operating system and/or window manager). If the
> +     * enabled on the underlying operating system and/or window manager. If the
>        * platform supports it, {@code setDynamicLayout(boolean)} may be used to
>        * programmatically enable or disable platform dynamic layout. Regardless of
>        * whether that toggling is supported, or whether {@code true} or {@code


From rajeev.chamyal at oracle.com  Fri Sep  2 11:37:20 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Fri, 2 Sep 2016 04:37:20 -0700 (PDT)
Subject: <AWT Dev> [9] Review Request JDK-8149371 multi-res. image:
 -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for
 Window.setIconImages
Message-ID: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>

Hello All,

 

Please review the following webrev.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8149371 

Webrev: http://cr.openjdk.java.net/~rchamyal/8149371/webrev.00/ 

 

Issue: Multiresolution icons are not working with -Dsun.java2d.uiScale.

Fix: Updated the implementation of SunToolkit:getScaledIconImage  to extract appropriate Multiresolution image and consider it in the existing algorithm for finding best image.

Java doc for Window:setIconImages is also updated.

 

Regards,

Rajeev Chamyal

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160902/97b1182b/attachment.html>

From kumar.x.srinivasan at oracle.com  Fri Sep  2 13:39:56 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 02 Sep 2016 06:39:56 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
Message-ID: <57C9812C.1080104@oracle.com>


Hi,

> Hello Kumar,
>
> I have further updated launcher.properties.
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>
> For documentation update I have already raise a bug.
> https://bugs.openjdk.java.net/browse/JDK-8165009

Ok.

so what about ?

http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java


This is the SplashScreen specification, is it not ? But there seems to be no
effort to clarify this specification ?

Kumar

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 01 September 2016 19:17
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; Philip Race
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
>
> Hello Rajeev,
>
> IMHO, this really belongs here:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java
>
> and here:
>
> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>
> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>
>
> Kumar
>
>
>
>> Hello Kumar,
>>
>> Can you please review the updated
>> src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Philip Race
>> Sent: 27 August 2016 03:10
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify
>> the HiDPI splash screen image naming convention
>>
>> Seems fine now.
>> 1) Please do a CCC for this
>> 2) Please file a doc. bug so docs team can update the HTML man page
>> and also perhaps
>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.html
>>
>> -phil
>>
>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> Please review the updated webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexandr Scherbatiy
>>> Sent: 25 August 2016 22:07
>>> To: Rajeev Chamyal; Philip Race
>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>> Hello Phil,
>>>>
>>>> Thanks for the review,
>>>> Please review updated webrev.
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>> Updated files:
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>>> e s
>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.h
>>>        The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>
>>>       Thanks,
>>>       Alexandr.
>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Phil Race
>>>> Sent: 20 August 2016 01:47
>>>> To: Rajeev Chamyal
>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>
>>>> -phil.
>>>>
>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>> Hello Phil,
>>>>>
>>>>> Please review the updated webrev.
>>>>>
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>
>>>>> Updated file
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>>> i
>>>>> e
>>>>> s
>>>>>
>>>>> Added all other supported name extensions.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajeev Chamyal
>>>>>
>>>>> *From:*Philip Race
>>>>> *Sent:* 19 August 2016 04:48
>>>>> *To:* Rajeev Chamyal
>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>> Scherbatiy
>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> Better, although it still does not document the supported set of
>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>         Hello Phil,
>>>>>
>>>>>         Thanks for the review.
>>>>>
>>>>>         Please review the updated webrev.
>>>>>
>>>>>         http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>         <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>
>>>>>         Updated file
>>>>>
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>>> i
>>>>> e
>>>>> s
>>>>>
>>>>>         Regards,
>>>>>
>>>>>         Rajeev Chamyal
>>>>>
>>>>>         *From:*Phil Race
>>>>>         *Sent:* 16 August 2016 22:28
>>>>>         *To:* Alexandr Scherbatiy
>>>>>         *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>         <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>         *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>         Unify the HiDPI splash screen image naming convention
>>>>>
>>>>>         On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>
>>>>>
>>>>>             The fix looks good to me.
>>>>>
>>>>>             It would be better if a native speaker look at the
>>>>>             documentation change in the launcher.properties file.
>>>>>
>>>>>
>>>>>         That documentation seems to cover only *some* of the extensions we
>>>>>         discussed.
>>>>>         It ought to cite all of them if it does so at all. How else are
>>>>>         people supposed
>>>>>         to know what they can use ? Where else are you documenting it?
>>>>>         Perhaps the launcher "man" page should be updated too
>>>>>         find . -name java.1
>>>>>         ./src/linux/doc/man/java.1
>>>>>         ./src/linux/doc/man/ja/java.1
>>>>>         ./src/bsd/doc/man/java.1
>>>>>         ./src/bsd/doc/man/ja/java.1
>>>>>         ./src/solaris/doc/sun/man/man1/java.1
>>>>>         ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>
>>>>>         .. although I think there is also some HTML version maintained by
>>>>>         the pubs/docs team
>>>>>         that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>         I don't know offhand what is recommended these days. We'll have to
>>>>>         find someone
>>>>>         who does more with the launcher to help point to where to do the
>>>>>         documentation.
>>>>>
>>>>>         And the doc does not really explain what is going on here. Reading
>>>>>         that I might
>>>>>         think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>         hi-dpi image
>>>>>         and that is not the idea at all, is it ?
>>>>>         The idea is you would still specify -splash:image.ext and the
>>>>>         *implementation*
>>>>>         will look for the most appropriate scaled image for the current
>>>>>         desktop.
>>>>>
>>>>>         I think we should also have a CCC cover this (somehow).
>>>>>
>>>>>         -phil.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             Thanks,
>>>>>             Alexandr.
>>>>>
>>>>>             On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>                 Hello Alexandr,
>>>>>
>>>>>                 Please review the updated webrev.
>>>>>
>>>>>                 
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>
>>>>>                 Updates :
>>>>>
>>>>>                 1)Updated the consition as suggested  if(*scaleFactor -
>>>>>                 (int)*scaleFactor<  0.000001)
>>>>>
>>>>>                 2)Includes the changes of
>>>>>
>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>
>>>>>                 3)+        //map the splash co-ordinates as per system scale
>>>>>                 +        splash->x /= splash->scaleFactor;
>>>>>                 +        splash->y /= splash->scaleFactor;
>>>>>
>>>>>
>>>>>
>>>>>                 This change is required only for windows and linux. As we
>>>>>                 use absolute system resolution for centring the splash on
>>>>>                 screen on these.
>>>>>
>>>>>                 i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>                 resolution) on windows and linux we use this for centring
>>>>>                 the splash on screen. For mac scaled resolution is used
>>>>>                 directly.
>>>>>
>>>>>                 Regards,
>>>>>
>>>>>                 Rajeev Chamyal
>>>>>
>>>>>                 *From:*Alexander Scherbatiy
>>>>>                 *Sent:* 11 August 2016 14:44
>>>>>                 *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>                 <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>                 Bylokhov
>>>>>                 *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>                 JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>                 convention
>>>>>
>>>>>                 On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>
>>>>>
>>>>>
>>>>>                     On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>                         Hello All,
>>>>>
>>>>>                         Please review the following webrev.
>>>>>
>>>>>                         Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>
>>>>>                         Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>
>>>>>
>>>>>                         Issue: Currently different naming conventions are
>>>>>                         used for Hidpi image on different platforms.
>>>>>
>>>>>                         With this change the names will be unified across
>>>>>                         all platforms.
>>>>>
>>>>>                         For a unscaled image image.ext following naming
>>>>>                         convention will be followed.
>>>>>
>>>>>                         Unscaled name: image.ext
>>>>>
>>>>>                         Supported Scaled Names:
>>>>>
>>>>>                         If screen scale is integer number e.g. 2:
>>>>>                         image at 2x.ext<mailto:image at 2x.ext>
>>>>>
>>>>>                         If screen scale is float value like 1.25:
>>>>>                         image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>
>>>>>
>>>>>                     The fix should be reviewed on the awt-dev alias.
>>>>>
>>>>>                     + if(*scaleFactor - (int)*scaleFactor<
>>>>> 0.000001)
>>>>>
>>>>>                     Should there be so high precision there? Could only
>>>>>                     percent values be compared like
>>>>>                      if ((*scaleFactor *100) !=
>>>>> ((int)(*scaleFactor))
>>>>> *
>>>>> 100)
>>>>>
>>>>>
>>>>>                     +        //map the splash co-ordinates as per system scale
>>>>>                     +        splash->x /= splash->scaleFactor;
>>>>>                     +        splash->y /= splash->scaleFactor;
>>>>>
>>>>>                     It looks like the splash coordinates and sizes are
>>>>>                     rescaled in different places. Is it possible to do
>>>>>                     that in the same place? May be in
>>>>>                     java_awt_SplashScreen.c file getBounds() function?
>>>>>
>>>>>
>>>>>                 src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>                        *scaleFactor = getNativeScaleFactor();
>>>>>
>>>>>                 Could you also include the change which requires to add
>>>>>                 some default output screen name to the
>>>>>                 getNativeScaleFactor() function on Linux. There is the
>>>>>                 discussion about that:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.h
>>>>> t
>>>>> m
>>>>> l
>>>>>
>>>>>                 Thanks,
>>>>>                 Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     Thanks,
>>>>>                     Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         Regards,
>>>>>
>>>>>                         Rajeev Chamyal
>>>>>


From iris.clark at oracle.com  Fri Sep  2 15:53:38 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Fri, 2 Sep 2016 08:53:38 -0700 (PDT)
Subject: <AWT Dev> RFR (XXS) 8165269: (doc)
 Toolkit.isDynamicLayoutActive(): orphan '0' in first sentence
In-Reply-To: <57d00838-fcf7-e022-acda-f55e4d8ef2c0@oracle.com>
References: <ad4d9d3c-3a5a-4bb4-b1b0-45b28a3918b9@default>
	<57d00838-fcf7-e022-acda-f55e4d8ef2c0@oracle.com>
Message-ID: <0480cc13-ab26-46de-b541-1ccf09a14609@default>

Hi, Alexandr.

Thanks for Reviewing.

I'll send a private message providing details for Sponsorship.

Regards,
iris

-----Original Message-----
From: Alexandr Scherbatiy 
Sent: Friday, September 02, 2016 2:52 AM
To: Iris Clark; aw >> OpenJDK awt-dev
Subject: Re: <AWT Dev> RFR (XXS) 8165269: (doc) Toolkit.isDynamicLayoutActive(): orphan '0' in first sentence


   The fix looks good to me.

   Thanks,
   Alexandr.

From anton.tarasov at jetbrains.com  Mon Sep  5 08:08:02 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Mon, 5 Sep 2016 11:08:02 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
 skip the activation/focus events
In-Reply-To: <2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
	<CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
	<765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>
	<2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>
Message-ID: <59434630-6dec-05be-e118-92cafc6b00d9@jetbrains.com>

Hi Sergey,

On 9/1/2016 5:22 PM, Anton Tarasov wrote:
> On 01 Sep 2016, at 14:31, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>> On 01.09.16 12:51, Anton Tarasov wrote:
>>> On 31 Aug 2016, at 21:04, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>>>> On 30.08.16 18:18, Anton Tarasov wrote:
>>>>>>> As I wrote in JIRA, the problem is caused by the fact that a native
>>>>>>> window (for a modal dialog) is shown before the peer starts to show.
>>>>>>> (This seems strange, and you can investigate the reason, I?m not aware)
>>>>>> Maybe because NSWindow.orderFrontRegardless() is called? Why it is
>>>>>> called on that moment and why the "Regardless" version is used?
>>>>> Well, I suggest a one-line fix, harmless from my point of view. And I'm
>>>>> pointing to a problematic spot alongside. I'd love to know why modal
>>>>> dialogs are shown that way, but I'm afraid there was a hidden reason.
>>>> I wonder how do you use this dialogs, because it is not possible to dispose or make them invisible. For example all tests should dispose all windows which were created in the test, and it seems impossible in the provided code, right(tested on latest jdk9)?
>>> What do you mean? Ok, I simply tried to dispose it, it disappeared (well, I didn?t debug to check if it was disposed properly, but visually I see no problem). So, please clarify.
>> I just check on the latest jdk9 and jdk8u101, I add these lines to the test:
>>   f.setVisible(true);
>>   d.setVisible(true);
>> + f.dispose();
>> + d.dispose();
>>
>> but both frames are still visible. This is why I wonder, how did you close it in the app.
> You probably missed the fact the dialog is modal.
>
> Anton.

so do you have any more concerns about the dialogs?

Regards,
Anton.

>
>>> Why do I have to dispose all windows in a reg test?
>>>
>>> Of course I tested it, on jdk9 of a version matching the date of submitting the fix.
>>>
>>> Regards,
>>> Anton.
>>>
>>>>>> --Semyon
>>>>>>> The problem is thus specific to OSX.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anton.
>>>>>>>
>>>>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> is it really OS X only problem? It seems on other platforms the peer
>>>>>>>> focusability is updated in the same way.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the fix:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>>>>>
>>>>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>>>>> events on OSX.
>>>>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>>>>> earlier, in its ctor.
>>>>>>>>> Please find more details in JIRA.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>
>>>> --
>>>> Best regards, Sergey.
>>
>> -- 
>> Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Mon Sep  5 10:34:15 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Mon, 5 Sep 2016 13:34:15 +0300
Subject: <AWT Dev> [9] Review Request JDK-8149371 multi-res. image:
 -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for
 Window.setIconImages
In-Reply-To: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>
References: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>
Message-ID: <4e4ab82e-60fd-bd7b-dec3-1a02478c79e6@oracle.com>

On 9/2/2016 2:37 PM, Rajeev Chamyal wrote:
>
> Hello All,
>
> Please review the following webrev.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149371
>
> Webrev: http://cr.openjdk.java.net/~rchamyal/8149371/webrev.00/ 
> <http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.00/>
>
> Issue: Multiresolution icons are not working with -Dsun.java2d.uiScale.
>
> Fix: Updated the implementation of SunToolkit:getScaledIconImage  to 
> extract appropriate Multiresolution image and consider it in the 
> existing algorithm for finding best image.
>
> Java doc for Window:setIconImages is also updated.
>
   - It is possible to use only one ArrayList which initial size is 
number of images in the image list. Iterating over image list we can add 
to the array list an initial image if it is not instance of 
MultiResolutionImage or a resolution variant.
   - Is it required that images in the imageList are sorted?
   - It is better to reuse the dpi values in the awt_Window.cpp file 
(see fix for issue JDK-8158411)

   Thanks,
   Alexandr.

> Regards,
>
> Rajeev Chamyal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160905/48bb4639/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep  5 17:11:53 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Sep 2016 20:11:53 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
 skip the activation/focus events
In-Reply-To: <2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
	<CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
	<765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>
	<2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>
Message-ID: <21e7de35-bfa3-aca3-245b-ab6823831d09@oracle.com>

On 01.09.16 17:22, Anton Tarasov wrote:
>> but both frames are still visible. This is why I wonder, how did you close it in the app.
>
> You probably missed the fact the dialog is modal.

O_o, correct. No more comments from me. Looks fine. Thanks for the fix.

>
> Anton.
>
>>
>>>
>>> Why do I have to dispose all windows in a reg test?
>>>
>>> Of course I tested it, on jdk9 of a version matching the date of submitting the fix.
>>>
>>> Regards,
>>> Anton.
>>>
>>>>
>>>>>> --Semyon
>>>>>>> The problem is thus specific to OSX.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Anton.
>>>>>>>
>>>>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>>>
>>>>>>>> Hi Anton,
>>>>>>>>
>>>>>>>> is it really OS X only problem? It seems on other platforms the peer
>>>>>>>> focusability is updated in the same way.
>>>>>>>>
>>>>>>>> --Semyon
>>>>>>>>
>>>>>>>>
>>>>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the fix:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>>>>>
>>>>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>>>>> events on OSX.
>>>>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>>>>> earlier, in its ctor.
>>>>>>>>> Please find more details in JIRA.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep  5 18:14:39 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 5 Sep 2016 21:14:39 +0300
Subject: <AWT Dev> [9] Review request 8155083: On Windows,
 usage of USER_ATTENTION_WINDOW depends on state setting order
In-Reply-To: <a194e46f-fc63-3bd3-8c17-1050f546d7a1@oracle.com>
References: <37de76bc-4698-e716-6779-9e5acfa0f49f@oracle.com>
	<72cbee44-bf39-ada0-265c-818522183afe@oracle.com>
	<44f8eda3-384c-80f7-48db-85bc904c4066@oracle.com>
	<a194e46f-fc63-3bd3-8c17-1050f546d7a1@oracle.com>
Message-ID: <930a763d-48ea-28dc-36b5-c3b69917b0d6@oracle.com>

+1

On 01.09.16 14:29, Semyon Sadetsky wrote:
> I thought that the native Windows behavior is flashing it several times.
> But probably it is not true.
>
> Then the fix looks good.
>
> --Semyon
>
>
> On 01.09.2016 14:26, Alexander Zvegintsev wrote:
>> Hi Semyon,
>>
>> This is intended. Sure, it will(the issue is filed against this test
>> case, so it is the first test case I've checked).
>>
>>
>> On 9/1/16 10:45 AM, Semyon Sadetsky wrote:
>>> Hi Alexander,
>>>
>>> FlashWindow() flashes window only once. Before the fix it was 3
>>> times. Will it be ok for the iconified window state?
>>>
>>> --Semyon
>>>
>>>
>>> On 26.08.2016 05:53, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8155083/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8155083
>>>>
>>>> With current implementation we are showing initially iconified
>>>> window with SW_SHOWMINIMIZED flag, it activates the window,
>>>> FlashWindowEx doesn't work with active window.
>>>> We could use SW_SHOWMINNOACTIVE instead, but there is another issue:
>>>> if app has more than one window it doesn't work either.
>>>> The fix it to use FlashWindow().
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Tue Sep  6 09:16:06 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 6 Sep 2016 12:16:06 +0300
Subject: <AWT Dev> Review request for 8160570: [mac] modal dialog can
 skip the activation/focus events
In-Reply-To: <21e7de35-bfa3-aca3-245b-ab6823831d09@oracle.com>
References: <94F97299-9503-4D82-93AA-0E8C40AE7524@jetbrains.com>
	<a7ed3657-10f9-9190-29eb-7acb14e7bc1c@oracle.com>
	<6B46B8B4-1F8A-4E43-BA3F-D3DA627E829D@jetbrains.com>
	<04d135da-50f5-2d51-a9a0-0cf5f2a2b6ac@oracle.com>
	<6497d165-4720-9e47-1297-448542904f28@jetbrains.com>
	<3c9a3c53-5666-7da3-8b96-0f1f65d36638@oracle.com>
	<CA2759FE-CB77-4BC7-AB49-4446F23ABE67@jetbrains.com>
	<765aac26-a5f9-80ec-58ec-0c2d4cfb0658@oracle.com>
	<2CC43705-F41D-4C1C-8DFA-53C0F484EF84@jetbrains.com>
	<21e7de35-bfa3-aca3-245b-ab6823831d09@oracle.com>
Message-ID: <e8c81afb-fcfd-1b76-ecc8-fa178b4020be@jetbrains.com>

On 9/5/2016 8:11 PM, Sergey Bylokhov wrote:
> On 01.09.16 17:22, Anton Tarasov wrote:
>>> but both frames are still visible. This is why I wonder, how did you 
>>> close it in the app.
>>
>> You probably missed the fact the dialog is modal.
>
> O_o, correct. No more comments from me. Looks fine. Thanks for the fix.

Thanks for the review. I'll also request for pushing it to 8u-dev as well.

Regards,
Anton.


>
>>
>> Anton.
>>
>>>
>>>>
>>>> Why do I have to dispose all windows in a reg test?
>>>>
>>>> Of course I tested it, on jdk9 of a version matching the date of 
>>>> submitting the fix.
>>>>
>>>> Regards,
>>>> Anton.
>>>>
>>>>>
>>>>>>> --Semyon
>>>>>>>> The problem is thus specific to OSX.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Anton.
>>>>>>>>
>>>>>>>>> On 29 Aug 2016, at 19:30, Semyon Sadetsky
>>>>>>>>> <semyon.sadetsky at oracle.com> wrote:
>>>>>>>>>
>>>>>>>>> Hi Anton,
>>>>>>>>>
>>>>>>>>> is it really OS X only problem? It seems on other platforms 
>>>>>>>>> the peer
>>>>>>>>> focusability is updated in the same way.
>>>>>>>>>
>>>>>>>>> --Semyon
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/29/2016 9:04 PM, Anton Tarasov wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> Please review the fix:
>>>>>>>>>>
>>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8160570
>>>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8160570/webrev.0
>>>>>>>>>> <http://cr.openjdk.java.net/%7Eant/JDK-8160570/webrev.0>
>>>>>>>>>>
>>>>>>>>>> The problem is that a modal dialog can skip the activation/focus
>>>>>>>>>> events on OSX.
>>>>>>>>>> The fix is to cache the focusability state of the Window peer
>>>>>>>>>> earlier, in its ctor.
>>>>>>>>>> Please find more details in JIRA.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Anton.
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Best regards, Sergey.
>>>>
>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>
>


From Alan.Burlison at oracle.com  Tue Sep  6 10:16:29 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 6 Sep 2016 11:16:29 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
Message-ID: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>

XKeycodeToKeysym is deprecated and when compiled on Solaris 12 with 
warnings-as-errors this causes a compile time failure. References to 
XKeycodeToKeysym should be replaced by XkbKeycodeToKeysym. As this is 
common XOrg code it will affect Linux as well.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8165232
Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165232/

Thanks,

-- 
Alan Burlison
--

From rajeev.chamyal at oracle.com  Tue Sep  6 10:30:09 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 6 Sep 2016 03:30:09 -0700 (PDT)
Subject: <AWT Dev> [9] Review Request JDK-8149371 multi-res. image:
 -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for
 Window.setIconImages
In-Reply-To: <4e4ab82e-60fd-bd7b-dec3-1a02478c79e6@oracle.com>
References: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>
	<4e4ab82e-60fd-bd7b-dec3-1a02478c79e6@oracle.com>
Message-ID: <48e010c5-f33b-4101-abef-b89de1a9f94b@default>

Hello Alexander,

 

Thanks for the review.I have updated webrev as per review comments.

http://cr.openjdk.java.net/~rchamyal/8149371/webrev.01/

 

Regards,

Rajeev Chamyal

 

From: Alexandr Scherbatiy 
Sent: 05 September 2016 16:04
To: Rajeev Chamyal; Sergey Bylokhov; awt-dev at openjdk.java.net
Subject: Re: <AWT Dev>[9] Review Request JDK-8149371 multi-res. image: -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for Window.setIconImages

 

On 9/2/2016 2:37 PM, Rajeev Chamyal wrote:



Hello All,

 

Please review the following webrev.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8149371 

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.00/"http://cr.openjdk.java.net/~rchamyal/8149371/webrev.00/ 

 

Issue: Multiresolution icons are not working with -Dsun.java2d.uiScale.

Fix: Updated the implementation of SunToolkit:getScaledIconImage  to extract appropriate Multiresolution image and consider it in the existing algorithm for finding best image.

Java doc for Window:setIconImages is also updated.

  - It is possible to use only one ArrayList which initial size is number of images in the image list. Iterating over image list we can add to the array list an initial image if it is not instance of MultiResolutionImage or a resolution variant.
  - Is it required that images in the imageList are sorted?
  - It is better to reuse the dpi values in the awt_Window.cpp file (see fix for issue JDK-8158411)

  Thanks,
  Alexandr.
 



 

Regards,

Rajeev Chamyal

 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160906/51a5eb7c/attachment-0001.html>

From alexandr.scherbatiy at oracle.com  Tue Sep  6 10:50:10 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Tue, 6 Sep 2016 13:50:10 +0300
Subject: <AWT Dev> [9] Review Request JDK-8149371 multi-res. image:
 -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for
 Window.setIconImages
In-Reply-To: <48e010c5-f33b-4101-abef-b89de1a9f94b@default>
References: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>
	<4e4ab82e-60fd-bd7b-dec3-1a02478c79e6@oracle.com>
	<48e010c5-f33b-4101-abef-b89de1a9f94b@default>
Message-ID: <11684527-6733-c11d-4398-c7fbaa99e5ed@oracle.com>

The fix looks good to me.

Thanks,
Alexandr.

On 9/6/2016 1:30 PM, Rajeev Chamyal wrote:
>
> Hello Alexander,
>
> Thanks for the review.I have updated webrev as per review comments.
>
> http://cr.openjdk.java.net/~rchamyal/8149371/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.01/>
>
> Regards,
>
> Rajeev Chamyal
>
> *From:*Alexandr Scherbatiy
> *Sent:* 05 September 2016 16:04
> *To:* Rajeev Chamyal; Sergey Bylokhov; awt-dev at openjdk.java.net
> *Subject:* Re: <AWT Dev>[9] Review Request JDK-8149371 multi-res. 
> image: -Dsun.java2d.uiScale does not work for Window icons (some 
> ambiguity for Window.setIconImages
>
> On 9/2/2016 2:37 PM, Rajeev Chamyal wrote:
>
>     Hello All,
>
>     Please review the following webrev.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8149371
>
>     Webrev: http://cr.openjdk.java.net/~rchamyal/8149371/webrev.00/
>     <http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.00/>
>
>     Issue: Multiresolution icons are not working with
>     -Dsun.java2d.uiScale.
>
>     Fix: Updated the implementation of SunToolkit:getScaledIconImage
>      to extract appropriate Multiresolution image and consider it in
>     the existing algorithm for finding best image.
>
>     Java doc for Window:setIconImages is also updated.
>
>   - It is possible to use only one ArrayList which initial size is 
> number of images in the image list. Iterating over image list we can 
> add to the array list an initial image if it is not instance of 
> MultiResolutionImage or a resolution variant.
>   - Is it required that images in the imageList are sorted?
>   - It is better to reuse the dpi values in the awt_Window.cpp file 
> (see fix for issue JDK-8158411)
>
>   Thanks,
>   Alexandr.
>
>
>     Regards,
>
>     Rajeev Chamyal
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160906/6182b0da/attachment.html>

From alexander.zvegintsev at oracle.com  Tue Sep  6 14:32:54 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 6 Sep 2016 17:32:54 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
Message-ID: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8143914


This fix adds the green FullScreen button to a resizable frames by default.

Previous maximize behavior is still accessible by holding Alt while 
clicking on the green button.

setResizable is fixed because of two reasons:

Window will not be able to leave fullscreen if we remove resizable from 
style bits(and even if we set it again)

Window will not have the green button(maximize/zoom or fullscreen) if 
the window was initially not resizable.


-- 
Thanks,
Alexander.


From Alan.Burlison at oracle.com  Tue Sep  6 09:24:59 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 6 Sep 2016 10:24:59 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
Message-ID: <0a0f64e8-b0f5-7a88-08a2-f7af990f0769@oracle.com>

XKeycodeToKeysym is deprecated and when compiled on Solaris 12 with 
warnings-as-errors this causes a compile time failure. References to 
XKeycodeToKeysym should be replaced by XkbKeycodeToKeysym. As this is 
common XOrg code it will affect Linux as well.

Bug:    https://bugs.openjdk.java.net/browse/JDK-8165232
Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165232/

Thanks,

-- 
Alan Burlison
--

From alexander.zvegintsev at oracle.com  Tue Sep  6 17:56:54 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 6 Sep 2016 20:56:54 +0300
Subject: <AWT Dev> [9] Review request for 8153526: [Unity]
 Taskbar.getTaskbar().setMenu(null) doesn't remove menu
Message-ID: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8153526/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8153526



-- 
Thanks,
Alexander.


From philip.race at oracle.com  Tue Sep  6 19:29:27 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 6 Sep 2016 12:29:27 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
Message-ID: <bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>

Alan,

You are removing this : native method

Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym There is no explanation 
about this .. and unless you discovered this method is obsolete (never 
called) it seems like it should also be updated .. not deleted. And 
since I see it called from XToolkit.java it appears updating is what is 
needed. You would then also need to revert the mapfile change. -phil.

On 9/6/2016 3:16 AM, Alan Burlison wrote:
> XKeycodeToKeysym is deprecated and when compiled on Solaris 12 with 
> warnings-as-errors this causes a compile time failure. References to 
> XKeycodeToKeysym should be replaced by XkbKeycodeToKeysym. As this is 
> common XOrg code it will affect Linux as well.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8165232
> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165232/
>
> Thanks,
>


From Alan.Burlison at oracle.com  Tue Sep  6 20:14:07 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 6 Sep 2016 21:14:07 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
Message-ID: <77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>

On 06/09/2016 20:29, Phil Race wrote:

> You are removing this : native method
>
> Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym There is no explanation
> about this .. and unless you discovered this method is obsolete (never
> called) it seems like it should also be updated .. not deleted. And
> since I see it called from XToolkit.java it appears updating is what is
> needed. You would then also need to revert the mapfile change.

Hmm, yes - good point... If 
Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym is only ever used within 
the AWT code then it could be replaced by calling 
Java_sun_awt_X11_XlibWrapper_XkbKeycodeToKeysym (which already exists). 
However if it is ever used outside then it's more of a problem. I wasn't 
sure if XlibWrapper.c was internal-only or not. If it isn't then I think 
the only option is to leave the 
Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym function in place and just 
change the implementation to use XkbKeycodeToKeysym underneath. If so, 
should Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym be flagged as 
deprecated?

In either case, I believe the existing Java calls to 
Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym need to be switched over 
to Java_sun_awt_X11_XlibWrapper_XkbKeycodeToKeysym. I thought I'd found 
those, clearly not.

Thanks for the catch,

-- 
Alan Burlison
--

From philip.race at oracle.com  Tue Sep  6 20:42:05 2016
From: philip.race at oracle.com (Phil Race)
Date: Tue, 6 Sep 2016 13:42:05 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
	<77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>
Message-ID: <98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>

On 9/6/2016 1:14 PM, Alan Burlison wrote:
> On 06/09/2016 20:29, Phil Race wrote:
>
>> You are removing this : native method
>>
>> Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym There is no explanation
>> about this .. and unless you discovered this method is obsolete (never
>> called) it seems like it should also be updated .. not deleted. And
>> since I see it called from XToolkit.java it appears updating is what is
>> needed. You would then also need to revert the mapfile change.
>
> Hmm, yes - good point... If 
> Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym is only ever used within 
> the AWT code then it could be replaced by calling 
> Java_sun_awt_X11_XlibWrapper_XkbKeycodeToKeysym (which already exists).

These are all internal-only entry points
So if that exists (I did not know that it did) then I think you have a 
few options but the most forward looking
is to get rid of all references to the deprecated methods and migrate 
all uses (inc. Java land ones) to the new code.

The declaration in XlibWrapper.java would need to be deleted.
And BTW if that is done then javac will helpfully find all the places 
that you need to fix .. assuming no use of reflection.

-phil.

> However if it is ever used outside then it's more of a problem. I 
> wasn't sure if XlibWrapper.c was internal-only or not. If it isn't 
> then I think the only option is to leave the 
> Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym function in place and 
> just change the implementation to use XkbKeycodeToKeysym underneath. 
> If so, should Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym be flagged 
> as deprecated?
>
> In either case, I believe the existing Java calls to 
> Java_sun_awt_X11_XlibWrapper_XKeycodeToKeysym need to be switched over 
> to Java_sun_awt_X11_XlibWrapper_XkbKeycodeToKeysym. I thought I'd 
> found those, clearly not.
>
> Thanks for the catch,
>


From Alan.Burlison at oracle.com  Tue Sep  6 21:03:00 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 6 Sep 2016 22:03:00 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
	<77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>
	<98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>
Message-ID: <ee099ca7-7e2b-9b0e-bbc4-0cda7e34713f@oracle.com>

On 06/09/2016 21:42, Phil Race wrote:

> These are all internal-only entry points So if that exists (I did not
> know that it did) then I think you have a few options but the most
> forward looking is to get rid of all references to the deprecated
> methods and migrate all uses (inc. Java land ones) to the new code.

Thanks for the detail, doing as you suggest and migrating all the 
references seems like the best approach as it shouldn't require any 
followup work in the future. I'll make the changes you've suggested, 
retest and post an updated webrev when I've done so.

> The declaration in XlibWrapper.java would need to be deleted. And BTW
> if that is done then javac will helpfully find all the places that
> you need to fix .. assuming no use of reflection.

I've done a text search for "XKeycodeToKeysym" across all the repos, the 
only uses I've been able to find are normal calls.

Thanks for the help,

-- 
Alan Burlison
--

From Alan.Burlison at oracle.com  Wed Sep  7 11:29:48 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Wed, 7 Sep 2016 12:29:48 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <ee099ca7-7e2b-9b0e-bbc4-0cda7e34713f@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
	<77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>
	<98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>
	<ee099ca7-7e2b-9b0e-bbc4-0cda7e34713f@oracle.com>
Message-ID: <019e1dcc-5c06-44c5-e4ba-501cc4112da1@oracle.com>

On 06/09/2016 22:03, Alan Burlison wrote:

> Thanks for the detail, doing as you suggest and migrating all the
> references seems like the best approach as it shouldn't require any
> followup work in the future. I'll make the changes you've suggested,
> retest and post an updated webrev when I've done so.

Unfortunately there's a wrinkle. In most cases it's easy enough to just 
replace calls to XKeycodeToKeysym() with XkbKeycodeToKeysym(), but 
there's some code that can't be dealt with that simply:

http://hg.openjdk.java.net/jdk9/dev/jdk/file/60d7fbe25cd7/src/java.desktop/unix/classes/sun/awt/X11/keysym2ucs.h#l135

There are two functions, xkeycode2keysym_noxkb() and 
xkeycode2keysym_xkb() the intent being that if the XKEYBOARD extension 
is not available the deprecated XKeycodeToKeysym() function that we want 
to remove is used, and if XKEYBOARD is present then an alternate 
mechanism is used (but not XkbKeycodeToKeysym(), strangely enough).

In the case of xkeycode2keysym_noxkb() it makes no sense to simply 
replace the call to XKeycodeToKeysym() with XkbKeycodeToKeysym() because 
xkeycode2keysym_noxkb() will only be called in the first place if the 
XKEYBOARD extension has not been loaded, and presumably a replacement 
call to XkbKeycodeToKeysym() would fail.

This ripples outwards - which of the _noxkb or _xkb variants is to be 
used is predicated on XToolkit.canUseXKBCalls(), that in turn uses the 
awt_UseXKB_Calls variable which is initialised in XToolkit.tryXKB() 
based on probing to see if there is a useable XKEYBOARD extension. 
Toolkit.canUseXKBCalls() is used in multiple other places as well.

The issue is that replacing calls to the deprecated XKeycodeToKeysym() 
function relies on XKEYBOARD always being loaded. Can that assumption be 
made for all X11-supporting platforms that Java9 will run on? If not, 
there doesn't seem to be any way to remove the use of the deprecated 
XKeycodeToKeysym(), unless someone can suggest an alternative that 
doesn't use XkbKeycodeToKeysym().

I also notice that many of the affected files also contain references to 
the obsolete Xsun server which was removed in Solaris 11. As Java9 will 
be Solaris11+ only, that code could be removed - should I log a bug to 
that effect?

-- 
Alan Burlison
--

From alexey.ivanov at oracle.com  Wed Sep  7 12:11:09 2016
From: alexey.ivanov at oracle.com (Alexey Ivanov)
Date: Wed, 7 Sep 2016 15:11:09 +0300
Subject: <AWT Dev>
 =?utf-8?b?5Zue5aSN77yaICDlm57lpI3vvJogQW4gaXNzdWUgb2Yg?=
 =?utf-8?q?OpenJRE?=
In-Reply-To: <tencent_3AB781053B83062545D4C6CB@qq.com>
References: <tencent_3AB781053B83062545D4C6CB@qq.com>
Message-ID: <1f677d84-531f-0b48-7cf3-87518837a0c4@oracle.com>

Hi Rong,

Using Java 2D, even in headless mode, implies there are font files in 
the system. If there are no fonts, it could fail.

So just install some fonts in your OS.


Regards,
Alexey

On 23.08.2016 13:13, 31731705 wrote:
> Hi Alexey,
>
> Sorry for so late response. To following codes
>
>         BufferedImage image = new BufferedImage(200, 200, 
> BufferedImage.TYPE_INT_RGB);
>         Graphics2D g2 = image.createGraphics();
>         FontMetrics fm = g2.getFontMetrics();
>
> If there are no any font files in system the code will cause 
> exception. The stack trace is below.
>
> Exception in thread "main" java.lang.NullPointerException
>         at 
> sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1264)
>         at 
> sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:219)
>         at sun.awt.FontConfiguration.init(FontConfiguration.java:107)
>         at 
> sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:753)
>         at sun.font.SunFontManager$2.run(SunFontManager.java:430)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at sun.font.SunFontManager.<init>(SunFontManager.java:375)
>         at sun.awt.X11FontManager.<init>(X11FontManager.java:32)
>         at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>         at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>         at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>         at java.lang.reflect.Constructor.newInstance(Constructor.java:408)
>         at java.lang.Class.newInstance(Class.java:433)
>         at sun.font.FontManagerFactory$1.run(FontManagerFactory.java:83)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at 
> sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:74)
>         at sun.font.SunFontManager.getInstance(SunFontManager.java:249)
>         at 
> sun.font.FontDesignMetrics.getMetrics(FontDesignMetrics.java:264)
>         at sun.java2d.SunGraphics2D.getFontMetrics(SunGraphics2D.java:845)
>         at rptgraph.ReportGenerator.main(ReportGenerator.java:374)
>
> If I put the font file LucidaSansRegular.ttf into jre/lib/fonts folder 
> the code won't cause exception but fm will get wrong value whether I 
> call the the statement g2.setFont(new Font(Font.DIALOG, Font.PLAIN, 
> 12)) or not.
>
> Yes, you are right. "By placing font files into jre/lib/fonts you 
> change the behavior of the JRE, and you get unexpected results."
> And I just wonder why a simple font file will change behavior of 
> OpenJRE, sounds a little incredible.
>
> Regards,
> Rong
>
> ------------------ ???? ------------------
> *???:* "Alexey Ivanov";<alexey.ivanov at oracle.com>;
> *????:* 2016?5?30?(???) ??6:12
> *???:* ""<31731705 at qq.com>; "Mario 
> Torre"<neugens.limasoftware at gmail.com>; "dalibor 
> topic"<dalibor.topic at oracle.com>;
> *??:* "awt-dev"<awt-dev at openjdk.java.net>;
> *??:* Re: <AWT Dev> ??? An issue of OpenJRE
>
> Hi Rong,
>
> OpenJDK comes without font files in its jre/lib. Does OpenJDK not work 
> as expected?
>
> By placing font files into jre/lib/fonts you change the behavior of 
> the JRE, and you get unexpected results. Just don't copy font files 
> into JRE directory. If you want to use additional fonts, install those 
> font according to your OS instructions.
>
> Oracle JDK has several font files in its jre/lib/fonts. Those fonts 
> are part of the JRE. If you remove them, you can get unexpected results.
>
>
> You say that the following code throws NullPointerException on the 
> third line:
>
>         BufferedImage image = new BufferedImage(200, 200, 
> BufferedImage.TYPE_INT_RGB);
>         Graphics2D g2 = image.createGraphics();
>         FontMetrics fm = g2.getFontMetrics();
>
> What is the current font selected into g2?
> Have you tried explicitly setting a font?
>
>         g2.setFont(new Font(Font.DIALOG, Font.PLAIN, 12));
>
> The stacktrace of NullPointerException could also help to diagnose the 
> problem. If you think it's a problem, you can submit a bug at 
> http://bugreport.java.com/
>
> In the bug report, describe your environment (OS etc), your version of 
> Java, provide any error messages you get and a test case to reproduce 
> the problem.
>
>
> Regards,
> Alexey
>
> On 21.05.2016 7:23, 31731705 wrote:
>> <SNIP>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160907/c45d4790/attachment.html>

From Sergey.Bylokhov at oracle.com  Thu Sep  8 13:53:56 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Sep 2016 16:53:56 +0300
Subject: <AWT Dev> [9] Review request for 8164536:
 enableSuddenTermination() - Not throws SecurityException if a security
 manager exists and it will not allow the caller to invoke System.exit
In-Reply-To: <bce2662e-18f7-7a80-b045-9f584b523180@oracle.com>
References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com>
	<137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com>
	<bce2662e-18f7-7a80-b045-9f584b523180@oracle.com>
Message-ID: <1412d092-84aa-23b9-c5f8-bfcdcf04f007@oracle.com>

On 31.08.16 3:27, Alexander Zvegintsev wrote:
> Hi Sergey,
>
> It could be, but actually RuntimePermission is used by eawt(sure we can
> change it too, but I don't see a point)

It is still unclear to me why in most of the place we check two 
permissions? Can you please clarify what is the purpose of 
canProcessApplicationEvents and showWindowWithoutWarningBanner and why 
both are related for example to removeAppEventListener() method.

>
> Please see the updated webrev:
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/01/
>
> --
> Thanks,
> Alexander.
>
> On 30.08.2016 22:44, Sergey Bylokhov wrote:
>> Hi, Alexander.
>> Probably the name of this permission can be added to AWTPermissions.java?
>> I am not sure why some of the methods require
>> "canProcessApplicationEvents" permission. For example
>> Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template
>> but it does not throw such exceptions and/or require similar permissions.
>>
>> On 30.08.16 21:58, Alexander Zvegintsev wrote:
>>> Hello,
>>>
>>> Please review the fix
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/
>>>
>>> for the issue
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8164536
>>>
>>> This fix add check for canProcessApplicationEvents runtime
>>> permission(currently used by eawt) for Desktop and Taskbar classes.
>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep  8 14:02:53 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 8 Sep 2016 17:02:53 +0300
Subject: <AWT Dev> [9] Review request for 8153526: [Unity]
 Taskbar.getTaskbar().setMenu(null) doesn't remove menu
In-Reply-To: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
References: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
Message-ID: <9fcfcf26-6a19-0aaa-e682-464f52adc1d1@oracle.com>

Hi, Alexander.
Please add some small evaluation of the bug to the CR.

On 06.09.16 20:56, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8153526/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8153526
>
>
>


-- 
Best regards, Sergey.

From alexander.zvegintsev at oracle.com  Thu Sep  8 14:35:15 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 8 Sep 2016 17:35:15 +0300
Subject: <AWT Dev> [9] Review request for 8153526: [Unity]
 Taskbar.getTaskbar().setMenu(null) doesn't remove menu
In-Reply-To: <9fcfcf26-6a19-0aaa-e682-464f52adc1d1@oracle.com>
References: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
	<9fcfcf26-6a19-0aaa-e682-464f52adc1d1@oracle.com>
Message-ID: <67c648fa-35ce-2675-8f67-8c40c8ff2c00@oracle.com>

Hi Sergey,

It looks like unity works only with first assigned quicklist 
(unity_launcher_entry_set_quicklist). Assigning a new one has no effect.

--
Thanks,
Alexander.

On 09/08/2016 05:02 PM, Sergey Bylokhov wrote:
> Hi, Alexander.
> Please add some small evaluation of the bug to the CR.
>
> On 06.09.16 20:56, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8153526/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8153526
>>
>>
>>
>
>


From alexander.zvegintsev at oracle.com  Thu Sep  8 15:02:36 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Thu, 8 Sep 2016 18:02:36 +0300
Subject: <AWT Dev> [9] Review request for 8164536:
 enableSuddenTermination() - Not throws SecurityException if a security
 manager exists and it will not allow the caller to invoke System.exit
In-Reply-To: <1412d092-84aa-23b9-c5f8-bfcdcf04f007@oracle.com>
References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com>
	<137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com>
	<bce2662e-18f7-7a80-b045-9f584b523180@oracle.com>
	<1412d092-84aa-23b9-c5f8-bfcdcf04f007@oracle.com>
Message-ID: <a981c7e1-bc9d-2f36-6b88-81b8841393cb@oracle.com>

Initially showWindowWithoutWarningBanner was added to deny the new API 
functions invocation without permission check,

but now it seems redundant, so I left only canProcessApplicationEvents 
in the new webrev:

cr.openjdk.java.net/~azvegint/jdk/9/8164536/02/

--
Thanks,
Alexander.

On 09/08/2016 04:53 PM, Sergey Bylokhov wrote:
> On 31.08.16 3:27, Alexander Zvegintsev wrote:
>> Hi Sergey,
>>
>> It could be, but actually RuntimePermission is used by eawt(sure we can
>> change it too, but I don't see a point)
>
> It is still unclear to me why in most of the place we check two 
> permissions? Can you please clarify what is the purpose of 
> canProcessApplicationEvents and showWindowWithoutWarningBanner and why 
> both are related for example to removeAppEventListener() method.
>
>>
>> Please see the updated webrev:
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/01/
>>
>> -- 
>> Thanks,
>> Alexander.
>>
>> On 30.08.2016 22:44, Sergey Bylokhov wrote:
>>> Hi, Alexander.
>>> Probably the name of this permission can be added to 
>>> AWTPermissions.java?
>>> I am not sure why some of the methods require
>>> "canProcessApplicationEvents" permission. For example
>>> Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template
>>> but it does not throw such exceptions and/or require similar 
>>> permissions.
>>>
>>> On 30.08.16 21:58, Alexander Zvegintsev wrote:
>>>> Hello,
>>>>
>>>> Please review the fix
>>>>
>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/
>>>>
>>>> for the issue
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8164536
>>>>
>>>> This fix add check for canProcessApplicationEvents runtime
>>>> permission(currently used by eawt) for Desktop and Taskbar classes.
>>>>
>>>>
>>>
>>>
>>
>
>


From alexander.zvegintsev at oracle.com  Thu Sep  8 22:06:03 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 9 Sep 2016 01:06:03 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8141528: Test
 closed/java/awt/FullScreen/DisplayMode/CycleDMImage.java fails for Ubuntu
 15.10
In-Reply-To: <56656973.2030608@oracle.com>
References: <56656973.2030608@oracle.com>
Message-ID: <03f097d1-195d-c7d0-e826-3fcb47083c7d@oracle.com>

Hi Semyon,

I believe that this webrev should be updated to use isUnityCompiz().

--
Thanks,
Alexander.

On 07.12.2015 14:11, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8141528
> webrev: http://cr.openjdk.java.net/~ssadetsky/8141528/webrev.00/
>
> Compiz WM requires override redirect for full-screen window to 
> preserve the full size upon display mode switching.
>
> --Semyon
>


From manajit.halder at oracle.com  Fri Sep  9 05:23:03 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Fri, 9 Sep 2016 10:53:03 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8163270: [macosx]
	Robot(gc) issue on dual-screen system.
Message-ID: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>


Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8163270

Webrev: 
http://cr.openjdk.java.net/~mhalder/8163270/webrev.00/

Issue: 
[macosx] Robot(gc) issue on dual-screen system.

Cause: 
Calculation of x coordinate value was wrong for the mouse cursor in the extended monitor.

Fix: 
Calculation corrected for x coordinate.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160909/f80177a5/attachment.html>

From rajeev.chamyal at oracle.com  Fri Sep  9 09:02:55 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Fri, 9 Sep 2016 02:02:55 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57C9812C.1080104@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
Message-ID: <a46028af-92fc-4032-8c74-70a951be2839@default>

Hello Kumar,Phil,

Please review the update updated webrev.

http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
Updates in files :
src/java.base/share/classes/sun/launcher/resources/launcher.properties
src/java.desktop/share/classes/java/awt/SplashScreen.java

Regards,
Rajeev Chamyal

-----Original Message-----
From: Kumar Srinivasan 
Sent: 02 September 2016 19:10
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; Philip Race
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention


Hi,

> Hello Kumar,
>
> I have further updated launcher.properties.
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>
> For documentation update I have already raise a bug.
> https://bugs.openjdk.java.net/browse/JDK-8165009

Ok.

so what about ?

http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java


This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?

Kumar

>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 01 September 2016 19:17
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
> Philip Race
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify 
> the HiDPI splash screen image naming convention
>
>
> Hello Rajeev,
>
> IMHO, this really belongs here:
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.des
> ktop/share/classes/java/awt/SplashScreen.java
>
> and here:
>
> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>
> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>
>
> Kumar
>
>
>
>> Hello Kumar,
>>
>> Can you please review the updated
>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>> s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Philip Race
>> Sent: 27 August 2016 03:10
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>> Unify the HiDPI splash screen image naming convention
>>
>> Seems fine now.
>> 1) Please do a CCC for this
>> 2) Please file a doc. bug so docs team can update the HTML man page 
>> and also perhaps 
>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.htm
>> l
>>
>> -phil
>>
>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>> Hello Alexandr,
>>>
>>> Please review the updated webrev.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Alexandr Scherbatiy
>>> Sent: 25 August 2016 22:07
>>> To: Rajeev Chamyal; Philip Race
>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>> Hello Phil,
>>>>
>>>> Thanks for the review,
>>>> Please review updated webrev.
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>> Updated files:
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>> i
>>>> e s
>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>> h
>>>        The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>
>>>       Thanks,
>>>       Alexandr.
>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Phil Race
>>>> Sent: 20 August 2016 01:47
>>>> To: Rajeev Chamyal
>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>
>>>> -phil.
>>>>
>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>> Hello Phil,
>>>>>
>>>>> Please review the updated webrev.
>>>>>
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>
>>>>> Updated file
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>> t
>>>>> i
>>>>> e
>>>>> s
>>>>>
>>>>> Added all other supported name extensions.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Rajeev Chamyal
>>>>>
>>>>> *From:*Philip Race
>>>>> *Sent:* 19 August 2016 04:48
>>>>> *To:* Rajeev Chamyal
>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>>> Scherbatiy
>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> Better, although it still does not document the supported set of 
>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>         Hello Phil,
>>>>>
>>>>>         Thanks for the review.
>>>>>
>>>>>         Please review the updated webrev.
>>>>>
>>>>>         http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>         
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>
>>>>>         Updated file
>>>>>
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>> t
>>>>> i
>>>>> e
>>>>> s
>>>>>
>>>>>         Regards,
>>>>>
>>>>>         Rajeev Chamyal
>>>>>
>>>>>         *From:*Phil Race
>>>>>         *Sent:* 16 August 2016 22:28
>>>>>         *To:* Alexandr Scherbatiy
>>>>>         *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>         <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>         *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>         Unify the HiDPI splash screen image naming convention
>>>>>
>>>>>         On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>
>>>>>
>>>>>             The fix looks good to me.
>>>>>
>>>>>             It would be better if a native speaker look at the
>>>>>             documentation change in the launcher.properties file.
>>>>>
>>>>>
>>>>>         That documentation seems to cover only *some* of the extensions we
>>>>>         discussed.
>>>>>         It ought to cite all of them if it does so at all. How else are
>>>>>         people supposed
>>>>>         to know what they can use ? Where else are you documenting it?
>>>>>         Perhaps the launcher "man" page should be updated too
>>>>>         find . -name java.1
>>>>>         ./src/linux/doc/man/java.1
>>>>>         ./src/linux/doc/man/ja/java.1
>>>>>         ./src/bsd/doc/man/java.1
>>>>>         ./src/bsd/doc/man/ja/java.1
>>>>>         ./src/solaris/doc/sun/man/man1/java.1
>>>>>         ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>
>>>>>         .. although I think there is also some HTML version maintained by
>>>>>         the pubs/docs team
>>>>>         that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>         I don't know offhand what is recommended these days. We'll have to
>>>>>         find someone
>>>>>         who does more with the launcher to help point to where to do the
>>>>>         documentation.
>>>>>
>>>>>         And the doc does not really explain what is going on here. Reading
>>>>>         that I might
>>>>>         think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>         hi-dpi image
>>>>>         and that is not the idea at all, is it ?
>>>>>         The idea is you would still specify -splash:image.ext and the
>>>>>         *implementation*
>>>>>         will look for the most appropriate scaled image for the current
>>>>>         desktop.
>>>>>
>>>>>         I think we should also have a CCC cover this (somehow).
>>>>>
>>>>>         -phil.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             Thanks,
>>>>>             Alexandr.
>>>>>
>>>>>             On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>                 Hello Alexandr,
>>>>>
>>>>>                 Please review the updated webrev.
>>>>>
>>>>>                 
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>
>>>>>                 Updates :
>>>>>
>>>>>                 1)Updated the consition as suggested  if(*scaleFactor -
>>>>>                 (int)*scaleFactor<  0.000001)
>>>>>
>>>>>                 2)Includes the changes of
>>>>>
>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>
>>>>>                 3)+        //map the splash co-ordinates as per system scale
>>>>>                 +        splash->x /= splash->scaleFactor;
>>>>>                 +        splash->y /= splash->scaleFactor;
>>>>>
>>>>>
>>>>>
>>>>>                 This change is required only for windows and linux. As we
>>>>>                 use absolute system resolution for centring the splash on
>>>>>                 screen on these.
>>>>>
>>>>>                 i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>                 resolution) on windows and linux we use this for centring
>>>>>                 the splash on screen. For mac scaled resolution is used
>>>>>                 directly.
>>>>>
>>>>>                 Regards,
>>>>>
>>>>>                 Rajeev Chamyal
>>>>>
>>>>>                 *From:*Alexander Scherbatiy
>>>>>                 *Sent:* 11 August 2016 14:44
>>>>>                 *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>                 <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>                 Bylokhov
>>>>>                 *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>                 JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>                 convention
>>>>>
>>>>>                 On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>
>>>>>
>>>>>
>>>>>                     On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>
>>>>>                         Hello All,
>>>>>
>>>>>                         Please review the following webrev.
>>>>>
>>>>>                         Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>
>>>>>                         Webrev:
>>>>>
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>
>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>
>>>>>
>>>>>                         Issue: Currently different naming conventions are
>>>>>                         used for Hidpi image on different platforms.
>>>>>
>>>>>                         With this change the names will be unified across
>>>>>                         all platforms.
>>>>>
>>>>>                         For a unscaled image image.ext following naming
>>>>>                         convention will be followed.
>>>>>
>>>>>                         Unscaled name: image.ext
>>>>>
>>>>>                         Supported Scaled Names:
>>>>>
>>>>>                         If screen scale is integer number e.g. 2:
>>>>>                         image at 2x.ext<mailto:image at 2x.ext>
>>>>>
>>>>>                         If screen scale is float value like 1.25:
>>>>>                         image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>
>>>>>
>>>>>                     The fix should be reviewed on the awt-dev alias.
>>>>>
>>>>>                     + if(*scaleFactor - (int)*scaleFactor<
>>>>> 0.000001)
>>>>>
>>>>>                     Should there be so high precision there? Could only
>>>>>                     percent values be compared like
>>>>>                      if ((*scaleFactor *100) !=
>>>>> ((int)(*scaleFactor))
>>>>> *
>>>>> 100)
>>>>>
>>>>>
>>>>>                     +        //map the splash co-ordinates as per system scale
>>>>>                     +        splash->x /= splash->scaleFactor;
>>>>>                     +        splash->y /= splash->scaleFactor;
>>>>>
>>>>>                     It looks like the splash coordinates and sizes are
>>>>>                     rescaled in different places. Is it possible to do
>>>>>                     that in the same place? May be in
>>>>>                     java_awt_SplashScreen.c file getBounds() function?
>>>>>
>>>>>
>>>>>                 src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>                        *scaleFactor = getNativeScaleFactor();
>>>>>
>>>>>                 Could you also include the change which requires to add
>>>>>                 some default output screen name to the
>>>>>                 getNativeScaleFactor() function on Linux. There is the
>>>>>                 discussion about that:
>>>>>
>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>> h
>>>>> t
>>>>> m
>>>>> l
>>>>>
>>>>>                 Thanks,
>>>>>                 Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     Thanks,
>>>>>                     Alexandr.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                         Regards,
>>>>>
>>>>>                         Rajeev Chamyal
>>>>>


From kumar.x.srinivasan at oracle.com  Fri Sep  9 16:01:55 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Fri, 09 Sep 2016 09:01:55 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <a46028af-92fc-4032-8c74-70a951be2839@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
Message-ID: <57D2DCF3.8000107@oracle.com>


Hi Rajeev,
In launcher.properties do you need an additional line to say,
one must use the filename conventions to specify resolution ?

btw: I think you have formatting/indent issues in this file:
libsplashscreen/splashscreen_impl.c


Thanks
Kumar


> Hello Kumar,Phil,
>
> Please review the update updated webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
> Updates in files :
> src/java.base/share/classes/sun/launcher/resources/launcher.properties
> src/java.desktop/share/classes/java/awt/SplashScreen.java
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 02 September 2016 19:10
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; Philip Race
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
>
> Hi,
>
>> Hello Kumar,
>>
>> I have further updated launcher.properties.
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>>
>> For documentation update I have already raise a bug.
>> https://bugs.openjdk.java.net/browse/JDK-8165009
> Ok.
>
> so what about ?
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.desktop/share/classes/java/awt/SplashScreen.java
>
>
> This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>
> Kumar
>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Kumar Srinivasan
>> Sent: 01 September 2016 19:17
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov;
>> Philip Race
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify
>> the HiDPI splash screen image naming convention
>>
>>
>> Hello Rajeev,
>>
>> IMHO, this really belongs here:
>>
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.des
>> ktop/share/classes/java/awt/SplashScreen.java
>>
>> and here:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>
>> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>>
>>
>> Kumar
>>
>>
>>
>>> Hello Kumar,
>>>
>>> Can you please review the updated
>>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>>> s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Philip Race
>>> Sent: 27 August 2016 03:10
>>> To: Rajeev Chamyal
>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> Seems fine now.
>>> 1) Please do a CCC for this
>>> 2) Please file a doc. bug so docs team can update the HTML man page
>>> and also perhaps
>>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.htm
>>> l
>>>
>>> -phil
>>>
>>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>>> Hello Alexandr,
>>>>
>>>> Please review the updated webrev.
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Alexandr Scherbatiy
>>>> Sent: 25 August 2016 22:07
>>>> To: Rajeev Chamyal; Philip Race
>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>>> Hello Phil,
>>>>>
>>>>> Thanks for the review,
>>>>> Please review updated webrev.
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>>> Updated files:
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>>> i
>>>>> e s
>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>>> h
>>>>         The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>>
>>>>        Thanks,
>>>>        Alexandr.
>>>>
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Phil Race
>>>>> Sent: 20 August 2016 01:47
>>>>> To: Rajeev Chamyal
>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander Scherbatiy
>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>>> Hello Phil,
>>>>>>
>>>>>> Please review the updated webrev.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>>
>>>>>> Updated file
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>>> t
>>>>>> i
>>>>>> e
>>>>>> s
>>>>>>
>>>>>> Added all other supported name extensions.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Rajeev Chamyal
>>>>>>
>>>>>> *From:*Philip Race
>>>>>> *Sent:* 19 August 2016 04:48
>>>>>> *To:* Rajeev Chamyal
>>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>>> Scherbatiy
>>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>> Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>> Better, although it still does not document the supported set of
>>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>          Hello Phil,
>>>>>>
>>>>>>          Thanks for the review.
>>>>>>
>>>>>>          Please review the updated webrev.
>>>>>>
>>>>>>          http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>>          
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>>
>>>>>>          Updated file
>>>>>>
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>>> t
>>>>>> i
>>>>>> e
>>>>>> s
>>>>>>
>>>>>>          Regards,
>>>>>>
>>>>>>          Rajeev Chamyal
>>>>>>
>>>>>>          *From:*Phil Race
>>>>>>          *Sent:* 16 August 2016 22:28
>>>>>>          *To:* Alexandr Scherbatiy
>>>>>>          *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>          <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>>          *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>>          Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>>          On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>>              The fix looks good to me.
>>>>>>
>>>>>>              It would be better if a native speaker look at the
>>>>>>              documentation change in the launcher.properties file.
>>>>>>
>>>>>>
>>>>>>          That documentation seems to cover only *some* of the extensions we
>>>>>>          discussed.
>>>>>>          It ought to cite all of them if it does so at all. How else are
>>>>>>          people supposed
>>>>>>          to know what they can use ? Where else are you documenting it?
>>>>>>          Perhaps the launcher "man" page should be updated too
>>>>>>          find . -name java.1
>>>>>>          ./src/linux/doc/man/java.1
>>>>>>          ./src/linux/doc/man/ja/java.1
>>>>>>          ./src/bsd/doc/man/java.1
>>>>>>          ./src/bsd/doc/man/ja/java.1
>>>>>>          ./src/solaris/doc/sun/man/man1/java.1
>>>>>>          ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>>
>>>>>>          .. although I think there is also some HTML version maintained by
>>>>>>          the pubs/docs team
>>>>>>          that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>>          I don't know offhand what is recommended these days. We'll have to
>>>>>>          find someone
>>>>>>          who does more with the launcher to help point to where to do the
>>>>>>          documentation.
>>>>>>
>>>>>>          And the doc does not really explain what is going on here. Reading
>>>>>>          that I might
>>>>>>          think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>>          hi-dpi image
>>>>>>          and that is not the idea at all, is it ?
>>>>>>          The idea is you would still specify -splash:image.ext and the
>>>>>>          *implementation*
>>>>>>          will look for the most appropriate scaled image for the current
>>>>>>          desktop.
>>>>>>
>>>>>>          I think we should also have a CCC cover this (somehow).
>>>>>>
>>>>>>          -phil.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>              Thanks,
>>>>>>              Alexandr.
>>>>>>
>>>>>>              On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>                  Hello Alexandr,
>>>>>>
>>>>>>                  Please review the updated webrev.
>>>>>>
>>>>>>                  
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>>
>>>>>>                  Updates :
>>>>>>
>>>>>>                  1)Updated the consition as suggested  if(*scaleFactor -
>>>>>>                  (int)*scaleFactor<  0.000001)
>>>>>>
>>>>>>                  2)Includes the changes of
>>>>>>
>>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>
>>>>>>                  3)+        //map the splash co-ordinates as per system scale
>>>>>>                  +        splash->x /= splash->scaleFactor;
>>>>>>                  +        splash->y /= splash->scaleFactor;
>>>>>>
>>>>>>
>>>>>>
>>>>>>                  This change is required only for windows and linux. As we
>>>>>>                  use absolute system resolution for centring the splash on
>>>>>>                  screen on these.
>>>>>>
>>>>>>                  i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>>                  resolution) on windows and linux we use this for centring
>>>>>>                  the splash on screen. For mac scaled resolution is used
>>>>>>                  directly.
>>>>>>
>>>>>>                  Regards,
>>>>>>
>>>>>>                  Rajeev Chamyal
>>>>>>
>>>>>>                  *From:*Alexander Scherbatiy
>>>>>>                  *Sent:* 11 August 2016 14:44
>>>>>>                  *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>                  <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>>                  Bylokhov
>>>>>>                  *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>                  JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>                  convention
>>>>>>
>>>>>>                  On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                      On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>                          Hello All,
>>>>>>
>>>>>>                          Please review the following webrev.
>>>>>>
>>>>>>                          Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>>
>>>>>>                          Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>>
>>>>>>
>>>>>>                          Issue: Currently different naming conventions are
>>>>>>                          used for Hidpi image on different platforms.
>>>>>>
>>>>>>                          With this change the names will be unified across
>>>>>>                          all platforms.
>>>>>>
>>>>>>                          For a unscaled image image.ext following naming
>>>>>>                          convention will be followed.
>>>>>>
>>>>>>                          Unscaled name: image.ext
>>>>>>
>>>>>>                          Supported Scaled Names:
>>>>>>
>>>>>>                          If screen scale is integer number e.g. 2:
>>>>>>                          image at 2x.ext<mailto:image at 2x.ext>
>>>>>>
>>>>>>                          If screen scale is float value like 1.25:
>>>>>>                          image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>>
>>>>>>
>>>>>>                      The fix should be reviewed on the awt-dev alias.
>>>>>>
>>>>>>                      + if(*scaleFactor - (int)*scaleFactor<
>>>>>> 0.000001)
>>>>>>
>>>>>>                      Should there be so high precision there? Could only
>>>>>>                      percent values be compared like
>>>>>>                       if ((*scaleFactor *100) !=
>>>>>> ((int)(*scaleFactor))
>>>>>> *
>>>>>> 100)
>>>>>>
>>>>>>
>>>>>>                      +        //map the splash co-ordinates as per system scale
>>>>>>                      +        splash->x /= splash->scaleFactor;
>>>>>>                      +        splash->y /= splash->scaleFactor;
>>>>>>
>>>>>>                      It looks like the splash coordinates and sizes are
>>>>>>                      rescaled in different places. Is it possible to do
>>>>>>                      that in the same place? May be in
>>>>>>                      java_awt_SplashScreen.c file getBounds() function?
>>>>>>
>>>>>>
>>>>>>                  src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>                         *scaleFactor = getNativeScaleFactor();
>>>>>>
>>>>>>                  Could you also include the change which requires to add
>>>>>>                  some default output screen name to the
>>>>>>                  getNativeScaleFactor() function on Linux. There is the
>>>>>>                  discussion about that:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>>> h
>>>>>> t
>>>>>> m
>>>>>> l
>>>>>>
>>>>>>                  Thanks,
>>>>>>                  Alexandr.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                      Thanks,
>>>>>>                      Alexandr.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                          Regards,
>>>>>>
>>>>>>                          Rajeev Chamyal
>>>>>>


From Sergey.Bylokhov at oracle.com  Fri Sep  9 16:38:32 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 9 Sep 2016 19:38:32 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8163270: [macosx]
 Robot(gc) issue on dual-screen system.
In-Reply-To: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>
References: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>
Message-ID: <5aac63b7-3947-8a4a-9a0e-8188238680bc@oracle.com>

Hi, Manajit.
I recognized that the test can be cleaned a little bit. We can move the 
code from the init() to main and remove all other unnecessary stuff: 
TestPassedException, pass(), setTimeoutTo(), etc.

On 09.09.16 8:23, Manajit Halder wrote:
>
> Hi All,
>
> Kindly review the fix for JDK9.
>
> *Bug*:
> _https://bugs.openjdk.java.net/browse/JDK-8163270_
> _
> _
> *Webrev*:
> http://cr.openjdk.java.net/~mhalder/8163270/webrev.00/
>
> *Issue: *
> [macosx] Robot(gc) issue on dual-screen system.
>
> *Cause: *
> Calculation of x coordinate value was wrong for the mouse cursor in the
> extended monitor.
>
> *Fix: *
> Calculation corrected for x coordinate.
>
> Regards,
> Manajit


-- 
Best regards, Sergey.

From Alan.Burlison at oracle.com  Fri Sep  9 22:41:55 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Fri, 9 Sep 2016 23:41:55 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<bc26f24d-3b52-ad30-b608-226902f746e0@oracle.com>
	<77049857-0726-568f-0f00-b4f5a9e9301a@oracle.com>
	<98d24470-f63a-37c8-951e-b901fef23a46@oracle.com>
Message-ID: <b154d8a2-2627-6a76-2855-9705855ba61d@oracle.com>

On 06/09/2016 21:42, Phil Race wrote:

> These are all internal-only entry points So if that exists (I did not
> know that it did) then I think you have a few options but the most
> forward looking is to get rid of all references to the deprecated
> methods and migrate all uses (inc. Java land ones) to the new code.
>
> The declaration in XlibWrapper.java would need to be deleted. And BTW
> if that is done then javac will helpfully find all the places that
> you need to fix .. assuming no use of reflection.

I have a first-pass attempt which passes JPRT but I'm not convinced it 
is going to be robust. I've updated 
https://bugs.openjdk.java.net/browse/JDK-8165232 with the details and 
with a suggested alternate approach, I'd appreciate any comments you have.

Thanks,

-- 
Alan Burlison
--

From rajeev.chamyal at oracle.com  Mon Sep 12 12:25:36 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Mon, 12 Sep 2016 05:25:36 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57D2DCF3.8000107@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
Message-ID: <01b1408e-76a8-4236-8286-45dd8e603b77@default>

Hello Kumar,

Thanks for the review.
Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/ 
Updates:
1) Updated launcher properties.
2) Corrected indentation in splashscreen_impl.c

Regards,
Rajeev Chamyal

-----Original Message-----
From: Kumar Srinivasan 
Sent: 09 September 2016 21:32
To: Rajeev Chamyal
Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention


Hi Rajeev,
In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?

btw: I think you have formatting/indent issues in this file:
libsplashscreen/splashscreen_impl.c


Thanks
Kumar


> Hello Kumar,Phil,
>
> Please review the update updated webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
> Updates in files :
> src/java.base/share/classes/sun/launcher/resources/launcher.properties
> src/java.desktop/share/classes/java/awt/SplashScreen.java
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 02 September 2016 19:10
> To: Rajeev Chamyal
> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
> Philip Race
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify 
> the HiDPI splash screen image naming convention
>
>
> Hi,
>
>> Hello Kumar,
>>
>> I have further updated launcher.properties.
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>>
>> For documentation update I have already raise a bug.
>> https://bugs.openjdk.java.net/browse/JDK-8165009
> Ok.
>
> so what about ?
>
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.des
> ktop/share/classes/java/awt/SplashScreen.java
>
>
> This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>
> Kumar
>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Kumar Srinivasan
>> Sent: 01 September 2016 19:17
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
>> Philip Race
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>> Unify the HiDPI splash screen image naming convention
>>
>>
>> Hello Rajeev,
>>
>> IMHO, this really belongs here:
>>
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
>> s ktop/share/classes/java/awt/SplashScreen.java
>>
>> and here:
>>
>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>
>> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>>
>>
>> Kumar
>>
>>
>>
>>> Hello Kumar,
>>>
>>> Can you please review the updated
>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>> e s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Philip Race
>>> Sent: 27 August 2016 03:10
>>> To: Rajeev Chamyal
>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>>> Unify the HiDPI splash screen image naming convention
>>>
>>> Seems fine now.
>>> 1) Please do a CCC for this
>>> 2) Please file a doc. bug so docs team can update the HTML man page 
>>> and also perhaps 
>>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.ht
>>> m
>>> l
>>>
>>> -phil
>>>
>>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>>> Hello Alexandr,
>>>>
>>>> Please review the updated webrev.
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Alexandr Scherbatiy
>>>> Sent: 25 August 2016 22:07
>>>> To: Rajeev Chamyal; Philip Race
>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>>> Hello Phil,
>>>>>
>>>>> Thanks for the review,
>>>>> Please review updated webrev.
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>>> Updated files:
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>> t
>>>>> i
>>>>> e s
>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>>> h
>>>>         The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>>
>>>>        Thanks,
>>>>        Alexandr.
>>>>
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Phil Race
>>>>> Sent: 20 August 2016 01:47
>>>>> To: Rajeev Chamyal
>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>>> Scherbatiy
>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>>> Hello Phil,
>>>>>>
>>>>>> Please review the updated webrev.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>>
>>>>>> Updated file
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>> r
>>>>>> t
>>>>>> i
>>>>>> e
>>>>>> s
>>>>>>
>>>>>> Added all other supported name extensions.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Rajeev Chamyal
>>>>>>
>>>>>> *From:*Philip Race
>>>>>> *Sent:* 19 August 2016 04:48
>>>>>> *To:* Rajeev Chamyal
>>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>>>> Scherbatiy
>>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request 
>>>>>> JDK-8151787 Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>> Better, although it still does not document the supported set of 
>>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>          Hello Phil,
>>>>>>
>>>>>>          Thanks for the review.
>>>>>>
>>>>>>          Please review the updated webrev.
>>>>>>
>>>>>>          http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>>          
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>>
>>>>>>          Updated file
>>>>>>
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>> r
>>>>>> t
>>>>>> i
>>>>>> e
>>>>>> s
>>>>>>
>>>>>>          Regards,
>>>>>>
>>>>>>          Rajeev Chamyal
>>>>>>
>>>>>>          *From:*Phil Race
>>>>>>          *Sent:* 16 August 2016 22:28
>>>>>>          *To:* Alexandr Scherbatiy
>>>>>>          *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>          <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>>          *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>>          Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>>          On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>>              The fix looks good to me.
>>>>>>
>>>>>>              It would be better if a native speaker look at the
>>>>>>              documentation change in the launcher.properties file.
>>>>>>
>>>>>>
>>>>>>          That documentation seems to cover only *some* of the extensions we
>>>>>>          discussed.
>>>>>>          It ought to cite all of them if it does so at all. How else are
>>>>>>          people supposed
>>>>>>          to know what they can use ? Where else are you documenting it?
>>>>>>          Perhaps the launcher "man" page should be updated too
>>>>>>          find . -name java.1
>>>>>>          ./src/linux/doc/man/java.1
>>>>>>          ./src/linux/doc/man/ja/java.1
>>>>>>          ./src/bsd/doc/man/java.1
>>>>>>          ./src/bsd/doc/man/ja/java.1
>>>>>>          ./src/solaris/doc/sun/man/man1/java.1
>>>>>>          ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>>
>>>>>>          .. although I think there is also some HTML version maintained by
>>>>>>          the pubs/docs team
>>>>>>          that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>>          I don't know offhand what is recommended these days. We'll have to
>>>>>>          find someone
>>>>>>          who does more with the launcher to help point to where to do the
>>>>>>          documentation.
>>>>>>
>>>>>>          And the doc does not really explain what is going on here. Reading
>>>>>>          that I might
>>>>>>          think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>>          hi-dpi image
>>>>>>          and that is not the idea at all, is it ?
>>>>>>          The idea is you would still specify -splash:image.ext and the
>>>>>>          *implementation*
>>>>>>          will look for the most appropriate scaled image for the current
>>>>>>          desktop.
>>>>>>
>>>>>>          I think we should also have a CCC cover this (somehow).
>>>>>>
>>>>>>          -phil.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>              Thanks,
>>>>>>              Alexandr.
>>>>>>
>>>>>>              On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>                  Hello Alexandr,
>>>>>>
>>>>>>                  Please review the updated webrev.
>>>>>>
>>>>>>                  
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>>
>>>>>>                  Updates :
>>>>>>
>>>>>>                  1)Updated the consition as suggested  if(*scaleFactor -
>>>>>>                  (int)*scaleFactor<  0.000001)
>>>>>>
>>>>>>                  2)Includes the changes of
>>>>>>
>>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>
>>>>>>                  3)+        //map the splash co-ordinates as per system scale
>>>>>>                  +        splash->x /= splash->scaleFactor;
>>>>>>                  +        splash->y /= splash->scaleFactor;
>>>>>>
>>>>>>
>>>>>>
>>>>>>                  This change is required only for windows and linux. As we
>>>>>>                  use absolute system resolution for centring the splash on
>>>>>>                  screen on these.
>>>>>>
>>>>>>                  i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>>                  resolution) on windows and linux we use this for centring
>>>>>>                  the splash on screen. For mac scaled resolution is used
>>>>>>                  directly.
>>>>>>
>>>>>>                  Regards,
>>>>>>
>>>>>>                  Rajeev Chamyal
>>>>>>
>>>>>>                  *From:*Alexander Scherbatiy
>>>>>>                  *Sent:* 11 August 2016 14:44
>>>>>>                  *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>                  <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>>                  Bylokhov
>>>>>>                  *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>                  JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>                  convention
>>>>>>
>>>>>>                  On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>                      On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>>
>>>>>>                          Hello All,
>>>>>>
>>>>>>                          Please review the following webrev.
>>>>>>
>>>>>>                          Bug:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>>
>>>>>>                          Webrev:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>>
>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>>
>>>>>>
>>>>>>                          Issue: Currently different naming conventions are
>>>>>>                          used for Hidpi image on different platforms.
>>>>>>
>>>>>>                          With this change the names will be unified across
>>>>>>                          all platforms.
>>>>>>
>>>>>>                          For a unscaled image image.ext following naming
>>>>>>                          convention will be followed.
>>>>>>
>>>>>>                          Unscaled name: image.ext
>>>>>>
>>>>>>                          Supported Scaled Names:
>>>>>>
>>>>>>                          If screen scale is integer number e.g. 2:
>>>>>>                          image at 2x.ext<mailto:image at 2x.ext>
>>>>>>
>>>>>>                          If screen scale is float value like 1.25:
>>>>>>                          
>>>>>> image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>>
>>>>>>
>>>>>>                      The fix should be reviewed on the awt-dev alias.
>>>>>>
>>>>>>                      + if(*scaleFactor - (int)*scaleFactor<
>>>>>> 0.000001)
>>>>>>
>>>>>>                      Should there be so high precision there? Could only
>>>>>>                      percent values be compared like
>>>>>>                       if ((*scaleFactor *100) !=
>>>>>> ((int)(*scaleFactor))
>>>>>> *
>>>>>> 100)
>>>>>>
>>>>>>
>>>>>>                      +        //map the splash co-ordinates as per system scale
>>>>>>                      +        splash->x /= splash->scaleFactor;
>>>>>>                      +        splash->y /= splash->scaleFactor;
>>>>>>
>>>>>>                      It looks like the splash coordinates and sizes are
>>>>>>                      rescaled in different places. Is it possible to do
>>>>>>                      that in the same place? May be in
>>>>>>                      java_awt_SplashScreen.c file getBounds() function?
>>>>>>
>>>>>>
>>>>>>                  src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>                         *scaleFactor = getNativeScaleFactor();
>>>>>>
>>>>>>                  Could you also include the change which requires to add
>>>>>>                  some default output screen name to the
>>>>>>                  getNativeScaleFactor() function on Linux. There is the
>>>>>>                  discussion about that:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>>> h
>>>>>> t
>>>>>> m
>>>>>> l
>>>>>>
>>>>>>                  Thanks,
>>>>>>                  Alexandr.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                      Thanks,
>>>>>>                      Alexandr.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>                          Regards,
>>>>>>
>>>>>>                          Rajeev Chamyal
>>>>>>


From kumar.x.srinivasan at oracle.com  Mon Sep 12 15:16:07 2016
From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan)
Date: Mon, 12 Sep 2016 08:16:07 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <01b1408e-76a8-4236-8286-45dd8e603b77@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
	<01b1408e-76a8-4236-8286-45dd8e603b77@default>
Message-ID: <57D6C6B7.6000104@oracle.com>

-\                  HiDPI and Non-HiDPI.Scaled filename convention should be\n\
+\                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
+\                  used for HiDPI images\n\

Space after .

Approved, contingent on the above fix, I don't need
to see another iteration.

Thanks
Kumar


On 9/12/2016 5:25 AM, Rajeev Chamyal wrote:
> Hello Kumar,
>
> Thanks for the review.
> Please review the updated webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
> Updates:
> 1) Updated launcher properties.
> 2) Corrected indentation in splashscreen_impl.c
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 09 September 2016 21:32
> To: Rajeev Chamyal
> Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
>
> Hi Rajeev,
> In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?
>
> btw: I think you have formatting/indent issues in this file:
> libsplashscreen/splashscreen_impl.c
>
>
> Thanks
> Kumar
>
>
>> Hello Kumar,Phil,
>>
>> Please review the update updated webrev.
>>
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
>> Updates in files :
>> src/java.base/share/classes/sun/launcher/resources/launcher.properties
>> src/java.desktop/share/classes/java/awt/SplashScreen.java
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Kumar Srinivasan
>> Sent: 02 September 2016 19:10
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov;
>> Philip Race
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify
>> the HiDPI splash screen image naming convention
>>
>>
>> Hi,
>>
>>> Hello Kumar,
>>>
>>> I have further updated launcher.properties.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>>>
>>> For documentation update I have already raise a bug.
>>> https://bugs.openjdk.java.net/browse/JDK-8165009
>> Ok.
>>
>> so what about ?
>>
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.des
>> ktop/share/classes/java/awt/SplashScreen.java
>>
>>
>> This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>>
>> Kumar
>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Kumar Srinivasan
>>> Sent: 01 September 2016 19:17
>>> To: Rajeev Chamyal
>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov;
>>> Philip Race
>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>>> Unify the HiDPI splash screen image naming convention
>>>
>>>
>>> Hello Rajeev,
>>>
>>> IMHO, this really belongs here:
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
>>> s ktop/share/classes/java/awt/SplashScreen.java
>>>
>>> and here:
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>
>>> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>>>
>>>
>>> Kumar
>>>
>>>
>>>
>>>> Hello Kumar,
>>>>
>>>> Can you please review the updated
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.properti
>>>> e s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Philip Race
>>>> Sent: 27 August 2016 03:10
>>>> To: Rajeev Chamyal
>>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> Seems fine now.
>>>> 1) Please do a CCC for this
>>>> 2) Please file a doc. bug so docs team can update the HTML man page
>>>> and also perhaps
>>>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.ht
>>>> m
>>>> l
>>>>
>>>> -phil
>>>>
>>>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>>>> Hello Alexandr,
>>>>>
>>>>> Please review the updated webrev.
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>>>
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alexandr Scherbatiy
>>>>> Sent: 25 August 2016 22:07
>>>>> To: Rajeev Chamyal; Philip Race
>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>>>> Hello Phil,
>>>>>>
>>>>>> Thanks for the review,
>>>>>> Please review updated webrev.
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>>>> Updated files:
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.proper
>>>>>> t
>>>>>> i
>>>>>> e s
>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>>>> h
>>>>>          The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>>>
>>>>>         Thanks,
>>>>>         Alexandr.
>>>>>
>>>>>> Regards,
>>>>>> Rajeev Chamyal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Phil Race
>>>>>> Sent: 20 August 2016 01:47
>>>>>> To: Rajeev Chamyal
>>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>>> Scherbatiy
>>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>> Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>>>> Hello Phil,
>>>>>>>
>>>>>>> Please review the updated webrev.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>>>
>>>>>>> Updated file
>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>>> r
>>>>>>> t
>>>>>>> i
>>>>>>> e
>>>>>>> s
>>>>>>>
>>>>>>> Added all other supported name extensions.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Rajeev Chamyal
>>>>>>>
>>>>>>> *From:*Philip Race
>>>>>>> *Sent:* 19 August 2016 04:48
>>>>>>> *To:* Rajeev Chamyal
>>>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>>>> Scherbatiy
>>>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>> JDK-8151787 Unify the HiDPI splash screen image naming convention
>>>>>>>
>>>>>>> Better, although it still does not document the supported set of
>>>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>           Hello Phil,
>>>>>>>
>>>>>>>           Thanks for the review.
>>>>>>>
>>>>>>>           Please review the updated webrev.
>>>>>>>
>>>>>>>           http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>>>           
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>>>
>>>>>>>           Updated file
>>>>>>>
>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>>> r
>>>>>>> t
>>>>>>> i
>>>>>>> e
>>>>>>> s
>>>>>>>
>>>>>>>           Regards,
>>>>>>>
>>>>>>>           Rajeev Chamyal
>>>>>>>
>>>>>>>           *From:*Phil Race
>>>>>>>           *Sent:* 16 August 2016 22:28
>>>>>>>           *To:* Alexandr Scherbatiy
>>>>>>>           *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>           <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>>>           *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>>>           Unify the HiDPI splash screen image naming convention
>>>>>>>
>>>>>>>           On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>               The fix looks good to me.
>>>>>>>
>>>>>>>               It would be better if a native speaker look at the
>>>>>>>               documentation change in the launcher.properties file.
>>>>>>>
>>>>>>>
>>>>>>>           That documentation seems to cover only *some* of the extensions we
>>>>>>>           discussed.
>>>>>>>           It ought to cite all of them if it does so at all. How else are
>>>>>>>           people supposed
>>>>>>>           to know what they can use ? Where else are you documenting it?
>>>>>>>           Perhaps the launcher "man" page should be updated too
>>>>>>>           find . -name java.1
>>>>>>>           ./src/linux/doc/man/java.1
>>>>>>>           ./src/linux/doc/man/ja/java.1
>>>>>>>           ./src/bsd/doc/man/java.1
>>>>>>>           ./src/bsd/doc/man/ja/java.1
>>>>>>>           ./src/solaris/doc/sun/man/man1/java.1
>>>>>>>           ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>>>
>>>>>>>           .. although I think there is also some HTML version maintained by
>>>>>>>           the pubs/docs team
>>>>>>>           that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>>>           I don't know offhand what is recommended these days. We'll have to
>>>>>>>           find someone
>>>>>>>           who does more with the launcher to help point to where to do the
>>>>>>>           documentation.
>>>>>>>
>>>>>>>           And the doc does not really explain what is going on here. Reading
>>>>>>>           that I might
>>>>>>>           think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>>>           hi-dpi image
>>>>>>>           and that is not the idea at all, is it ?
>>>>>>>           The idea is you would still specify -splash:image.ext and the
>>>>>>>           *implementation*
>>>>>>>           will look for the most appropriate scaled image for the current
>>>>>>>           desktop.
>>>>>>>
>>>>>>>           I think we should also have a CCC cover this (somehow).
>>>>>>>
>>>>>>>           -phil.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               Thanks,
>>>>>>>               Alexandr.
>>>>>>>
>>>>>>>               On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>                   Hello Alexandr,
>>>>>>>
>>>>>>>                   Please review the updated webrev.
>>>>>>>
>>>>>>>                   
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>>>
>>>>>>>                   Updates :
>>>>>>>
>>>>>>>                   1)Updated the consition as suggested  if(*scaleFactor -
>>>>>>>                   (int)*scaleFactor<  0.000001)
>>>>>>>
>>>>>>>                   2)Includes the changes of
>>>>>>>
>>>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>
>>>>>>>                   3)+        //map the splash co-ordinates as per system scale
>>>>>>>                   +        splash->x /= splash->scaleFactor;
>>>>>>>                   +        splash->y /= splash->scaleFactor;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                   This change is required only for windows and linux. As we
>>>>>>>                   use absolute system resolution for centring the splash on
>>>>>>>                   screen on these.
>>>>>>>
>>>>>>>                   i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>>>                   resolution) on windows and linux we use this for centring
>>>>>>>                   the splash on screen. For mac scaled resolution is used
>>>>>>>                   directly.
>>>>>>>
>>>>>>>                   Regards,
>>>>>>>
>>>>>>>                   Rajeev Chamyal
>>>>>>>
>>>>>>>                   *From:*Alexander Scherbatiy
>>>>>>>                   *Sent:* 11 August 2016 14:44
>>>>>>>                   *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>                   <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>>>                   Bylokhov
>>>>>>>                   *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>>                   JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>>                   convention
>>>>>>>
>>>>>>>                   On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                       On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>                           Hello All,
>>>>>>>
>>>>>>>                           Please review the following webrev.
>>>>>>>
>>>>>>>                           Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>>>
>>>>>>>                           Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>>>
>>>>>>>
>>>>>>>                           Issue: Currently different naming conventions are
>>>>>>>                           used for Hidpi image on different platforms.
>>>>>>>
>>>>>>>                           With this change the names will be unified across
>>>>>>>                           all platforms.
>>>>>>>
>>>>>>>                           For a unscaled image image.ext following naming
>>>>>>>                           convention will be followed.
>>>>>>>
>>>>>>>                           Unscaled name: image.ext
>>>>>>>
>>>>>>>                           Supported Scaled Names:
>>>>>>>
>>>>>>>                           If screen scale is integer number e.g. 2:
>>>>>>>                           image at 2x.ext<mailto:image at 2x.ext>
>>>>>>>
>>>>>>>                           If screen scale is float value like 1.25:
>>>>>>>                           
>>>>>>> image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>>>
>>>>>>>
>>>>>>>                       The fix should be reviewed on the awt-dev alias.
>>>>>>>
>>>>>>>                       + if(*scaleFactor - (int)*scaleFactor<
>>>>>>> 0.000001)
>>>>>>>
>>>>>>>                       Should there be so high precision there? Could only
>>>>>>>                       percent values be compared like
>>>>>>>                        if ((*scaleFactor *100) !=
>>>>>>> ((int)(*scaleFactor))
>>>>>>> *
>>>>>>> 100)
>>>>>>>
>>>>>>>
>>>>>>>                       +        //map the splash co-ordinates as per system scale
>>>>>>>                       +        splash->x /= splash->scaleFactor;
>>>>>>>                       +        splash->y /= splash->scaleFactor;
>>>>>>>
>>>>>>>                       It looks like the splash coordinates and sizes are
>>>>>>>                       rescaled in different places. Is it possible to do
>>>>>>>                       that in the same place? May be in
>>>>>>>                       java_awt_SplashScreen.c file getBounds() function?
>>>>>>>
>>>>>>>
>>>>>>>                   src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>                          *scaleFactor = getNativeScaleFactor();
>>>>>>>
>>>>>>>                   Could you also include the change which requires to add
>>>>>>>                   some default output screen name to the
>>>>>>>                   getNativeScaleFactor() function on Linux. There is the
>>>>>>>                   discussion about that:
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>>>> h
>>>>>>> t
>>>>>>> m
>>>>>>> l
>>>>>>>
>>>>>>>                   Thanks,
>>>>>>>                   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                       Thanks,
>>>>>>>                       Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                           Regards,
>>>>>>>
>>>>>>>                           Rajeev Chamyal
>>>>>>>


From ken.x.chen at oracle.com  Mon Sep 12 21:44:40 2016
From: ken.x.chen at oracle.com (Ken Chen)
Date: Mon, 12 Sep 2016 14:44:40 -0700
Subject: <AWT Dev> RFR: JDK-8165798 Fix license and copyright headers under
 test/java/awt
Message-ID: <74f15c99-3958-a062-402d-4cbc76c9e88d@oracle.com>

**

*Hello,*

*

Please review the patch below which fixes copyright in test files for awt


Bug:<https://bugs.openjdk.java.net/browse/JDK-8163991>https://bugs.openjdk.java.net/browse/JDK-8165798

Webrev: http://cr.openjdk.java.net/~shurailine/8165798/webrev.00/ 
<http://cr.openjdk.java.net/%7Eshurailine/8165798/webrev.00/>


Thanks,

-Ken*

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160912/f2337cbe/attachment.html>

From iris.clark at oracle.com  Mon Sep 12 22:11:21 2016
From: iris.clark at oracle.com (Iris Clark)
Date: Mon, 12 Sep 2016 15:11:21 -0700 (PDT)
Subject: <AWT Dev> RFR: JDK-8165798 Fix license and copyright headers
 under test/java/awt
In-Reply-To: <74f15c99-3958-a062-402d-4cbc76c9e88d@oracle.com>
References: <74f15c99-3958-a062-402d-4cbc76c9e88d@oracle.com>
Message-ID: <fd3080ca-3a47-481d-882b-c2f908f09b27@default>

Hi, Ken.

?

These changes appear to be the expected modifications.

?

The only potential problem I see is in test/java/awt/dnd/DnDFileGroupDescriptor/DnDfileGroupDescriptor.java [0] where it appears that an extra space has been inserted at line 24 immediately before the beginning of comment (column 0).

?

Thanks,

Iris

(not a Reviewer)

?

[0] http://cr.openjdk.java.net/~shurailine/8165798/webrev.00/test/java/awt/dnd/DnDFileGroupDescriptor/DnDFileGroupDescriptor.java.html

?

From: Ken Chen 
Sent: Monday, September 12, 2016 2:45 PM
To: awt-dev at openjdk.java.net
Cc: Ken Chen
Subject: <AWT Dev> RFR: JDK-8165798 Fix license and copyright headers under test/java/awt

?

Hello,

?

Please review the patch below which fixes copyright in test files for awt

?

Bug:HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8163991" https://bugs.openjdk.java.net/browse/JDK-8165798

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Eshurailine/8165798/webrev.00/"http://cr.openjdk.java.net/~shurailine/8165798/webrev.00/

?

Thanks,

-Ken
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160912/dc49db1e/attachment-0001.html>

From rajeev.chamyal at oracle.com  Tue Sep 13 07:03:02 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Tue, 13 Sep 2016 00:03:02 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57D6C6B7.6000104@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
	<01b1408e-76a8-4236-8286-45dd8e603b77@default>
	<57D6C6B7.6000104@oracle.com>
Message-ID: <bbfcbe03-a710-488f-a691-23c2c7ba4738@default>

Hello Phil,

Please review the updated webrev.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/

Updates:
Updated documentation in src/java.desktop/share/classes/java/awt/SplashScreen.java 
Review comments from Kumar are also updated in launcher.properties.

Regards,
Rajeev Chamyal

-----Original Message-----
From: Kumar Srinivasan 
Sent: 12 September 2016 20:46
To: Rajeev Chamyal
Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention

-\                  HiDPI and Non-HiDPI.Scaled filename convention should be\n\
+\                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
+\                  used for HiDPI images\n\

Space after .

Approved, contingent on the above fix, I don't need to see another iteration.

Thanks
Kumar


On 9/12/2016 5:25 AM, Rajeev Chamyal wrote:
> Hello Kumar,
>
> Thanks for the review.
> Please review the updated webrev.
>
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
> Updates:
> 1) Updated launcher properties.
> 2) Corrected indentation in splashscreen_impl.c
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 09 September 2016 21:32
> To: Rajeev Chamyal
> Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net; 
> Sergey Bylokhov
> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify 
> the HiDPI splash screen image naming convention
>
>
> Hi Rajeev,
> In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?
>
> btw: I think you have formatting/indent issues in this file:
> libsplashscreen/splashscreen_impl.c
>
>
> Thanks
> Kumar
>
>
>> Hello Kumar,Phil,
>>
>> Please review the update updated webrev.
>>
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
>> Updates in files :
>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>> s src/java.desktop/share/classes/java/awt/SplashScreen.java
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Kumar Srinivasan
>> Sent: 02 September 2016 19:10
>> To: Rajeev Chamyal
>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
>> Philip Race
>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>> Unify the HiDPI splash screen image naming convention
>>
>>
>> Hi,
>>
>>> Hello Kumar,
>>>
>>> I have further updated launcher.properties.
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>>>
>>> For documentation update I have already raise a bug.
>>> https://bugs.openjdk.java.net/browse/JDK-8165009
>> Ok.
>>
>> so what about ?
>>
>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
>> s ktop/share/classes/java/awt/SplashScreen.java
>>
>>
>> This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>>
>> Kumar
>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Kumar Srinivasan
>>> Sent: 01 September 2016 19:17
>>> To: Rajeev Chamyal
>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; 
>>> Philip Race
>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>>> Unify the HiDPI splash screen image naming convention
>>>
>>>
>>> Hello Rajeev,
>>>
>>> IMHO, this really belongs here:
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.d
>>> e s ktop/share/classes/java/awt/SplashScreen.java
>>>
>>> and here:
>>>
>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>
>>> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>>>
>>>
>>> Kumar
>>>
>>>
>>>
>>>> Hello Kumar,
>>>>
>>>> Can you please review the updated
>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>> i e s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Philip Race
>>>> Sent: 27 August 2016 03:10
>>>> To: Rajeev Chamyal
>>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>>>> Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>> Seems fine now.
>>>> 1) Please do a CCC for this
>>>> 2) Please file a doc. bug so docs team can update the HTML man page 
>>>> and also perhaps 
>>>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.h
>>>> t
>>>> m
>>>> l
>>>>
>>>> -phil
>>>>
>>>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>>>> Hello Alexandr,
>>>>>
>>>>> Please review the updated webrev.
>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>>>
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Alexandr Scherbatiy
>>>>> Sent: 25 August 2016 22:07
>>>>> To: Rajeev Chamyal; Philip Race
>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>>>> Hello Phil,
>>>>>>
>>>>>> Thanks for the review,
>>>>>> Please review updated webrev.
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>>>> Updated files:
>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>> r
>>>>>> t
>>>>>> i
>>>>>> e s
>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>>>> h
>>>>>          The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>>>
>>>>>         Thanks,
>>>>>         Alexandr.
>>>>>
>>>>>> Regards,
>>>>>> Rajeev Chamyal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Phil Race
>>>>>> Sent: 20 August 2016 01:47
>>>>>> To: Rajeev Chamyal
>>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>>>> Scherbatiy
>>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
>>>>>> Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>>>> Hello Phil,
>>>>>>>
>>>>>>> Please review the updated webrev.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>>>
>>>>>>> Updated file
>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prop
>>>>>>> e
>>>>>>> r
>>>>>>> t
>>>>>>> i
>>>>>>> e
>>>>>>> s
>>>>>>>
>>>>>>> Added all other supported name extensions.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Rajeev Chamyal
>>>>>>>
>>>>>>> *From:*Philip Race
>>>>>>> *Sent:* 19 August 2016 04:48
>>>>>>> *To:* Rajeev Chamyal
>>>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
>>>>>>> Scherbatiy
>>>>>>> *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>> JDK-8151787 Unify the HiDPI splash screen image naming 
>>>>>>> convention
>>>>>>>
>>>>>>> Better, although it still does not document the supported set of 
>>>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>           Hello Phil,
>>>>>>>
>>>>>>>           Thanks for the review.
>>>>>>>
>>>>>>>           Please review the updated webrev.
>>>>>>>
>>>>>>>           
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>>>           
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>>>
>>>>>>>           Updated file
>>>>>>>
>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prop
>>>>>>> e
>>>>>>> r
>>>>>>> t
>>>>>>> i
>>>>>>> e
>>>>>>> s
>>>>>>>
>>>>>>>           Regards,
>>>>>>>
>>>>>>>           Rajeev Chamyal
>>>>>>>
>>>>>>>           *From:*Phil Race
>>>>>>>           *Sent:* 16 August 2016 22:28
>>>>>>>           *To:* Alexandr Scherbatiy
>>>>>>>           *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>           <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>>>           *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>>>>           Unify the HiDPI splash screen image naming convention
>>>>>>>
>>>>>>>           On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>               The fix looks good to me.
>>>>>>>
>>>>>>>               It would be better if a native speaker look at the
>>>>>>>               documentation change in the launcher.properties file.
>>>>>>>
>>>>>>>
>>>>>>>           That documentation seems to cover only *some* of the extensions we
>>>>>>>           discussed.
>>>>>>>           It ought to cite all of them if it does so at all. How else are
>>>>>>>           people supposed
>>>>>>>           to know what they can use ? Where else are you documenting it?
>>>>>>>           Perhaps the launcher "man" page should be updated too
>>>>>>>           find . -name java.1
>>>>>>>           ./src/linux/doc/man/java.1
>>>>>>>           ./src/linux/doc/man/ja/java.1
>>>>>>>           ./src/bsd/doc/man/java.1
>>>>>>>           ./src/bsd/doc/man/ja/java.1
>>>>>>>           ./src/solaris/doc/sun/man/man1/java.1
>>>>>>>           ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>>>
>>>>>>>           .. although I think there is also some HTML version maintained by
>>>>>>>           the pubs/docs team
>>>>>>>           that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>>>           I don't know offhand what is recommended these days. We'll have to
>>>>>>>           find someone
>>>>>>>           who does more with the launcher to help point to where to do the
>>>>>>>           documentation.
>>>>>>>
>>>>>>>           And the doc does not really explain what is going on here. Reading
>>>>>>>           that I might
>>>>>>>           think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>>>           hi-dpi image
>>>>>>>           and that is not the idea at all, is it ?
>>>>>>>           The idea is you would still specify -splash:image.ext and the
>>>>>>>           *implementation*
>>>>>>>           will look for the most appropriate scaled image for the current
>>>>>>>           desktop.
>>>>>>>
>>>>>>>           I think we should also have a CCC cover this (somehow).
>>>>>>>
>>>>>>>           -phil.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>               Thanks,
>>>>>>>               Alexandr.
>>>>>>>
>>>>>>>               On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>                   Hello Alexandr,
>>>>>>>
>>>>>>>                   Please review the updated webrev.
>>>>>>>
>>>>>>>                   
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>>>
>>>>>>>                   Updates :
>>>>>>>
>>>>>>>                   1)Updated the consition as suggested  if(*scaleFactor -
>>>>>>>                   (int)*scaleFactor<  0.000001)
>>>>>>>
>>>>>>>                   2)Includes the changes of
>>>>>>>
>>>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>
>>>>>>>                   3)+        //map the splash co-ordinates as per system scale
>>>>>>>                   +        splash->x /= splash->scaleFactor;
>>>>>>>                   +        splash->y /= splash->scaleFactor;
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                   This change is required only for windows and linux. As we
>>>>>>>                   use absolute system resolution for centring the splash on
>>>>>>>                   screen on these.
>>>>>>>
>>>>>>>                   i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>>>                   resolution) on windows and linux we use this for centring
>>>>>>>                   the splash on screen. For mac scaled resolution is used
>>>>>>>                   directly.
>>>>>>>
>>>>>>>                   Regards,
>>>>>>>
>>>>>>>                   Rajeev Chamyal
>>>>>>>
>>>>>>>                   *From:*Alexander Scherbatiy
>>>>>>>                   *Sent:* 11 August 2016 14:44
>>>>>>>                   *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>                   <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>>>                   Bylokhov
>>>>>>>                   *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
>>>>>>>                   JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>>                   convention
>>>>>>>
>>>>>>>                   On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                       On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>>>
>>>>>>>                           Hello All,
>>>>>>>
>>>>>>>                           Please review the following webrev.
>>>>>>>
>>>>>>>                           Bug:
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>>>
>>>>>>>                           Webrev:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>>>
>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>>>
>>>>>>>
>>>>>>>                           Issue: Currently different naming conventions are
>>>>>>>                           used for Hidpi image on different platforms.
>>>>>>>
>>>>>>>                           With this change the names will be unified across
>>>>>>>                           all platforms.
>>>>>>>
>>>>>>>                           For a unscaled image image.ext following naming
>>>>>>>                           convention will be followed.
>>>>>>>
>>>>>>>                           Unscaled name: image.ext
>>>>>>>
>>>>>>>                           Supported Scaled Names:
>>>>>>>
>>>>>>>                           If screen scale is integer number e.g. 2:
>>>>>>>                           image at 2x.ext<mailto:image at 2x.ext>
>>>>>>>
>>>>>>>                           If screen scale is float value like 1.25:
>>>>>>>                           
>>>>>>> image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>>>
>>>>>>>
>>>>>>>                       The fix should be reviewed on the awt-dev alias.
>>>>>>>
>>>>>>>                       + if(*scaleFactor - (int)*scaleFactor<
>>>>>>> 0.000001)
>>>>>>>
>>>>>>>                       Should there be so high precision there? Could only
>>>>>>>                       percent values be compared like
>>>>>>>                        if ((*scaleFactor *100) !=
>>>>>>> ((int)(*scaleFactor))
>>>>>>> *
>>>>>>> 100)
>>>>>>>
>>>>>>>
>>>>>>>                       +        //map the splash co-ordinates as per system scale
>>>>>>>                       +        splash->x /= splash->scaleFactor;
>>>>>>>                       +        splash->y /= splash->scaleFactor;
>>>>>>>
>>>>>>>                       It looks like the splash coordinates and sizes are
>>>>>>>                       rescaled in different places. Is it possible to do
>>>>>>>                       that in the same place? May be in
>>>>>>>                       java_awt_SplashScreen.c file getBounds() function?
>>>>>>>
>>>>>>>
>>>>>>>                   src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>                          *scaleFactor = getNativeScaleFactor();
>>>>>>>
>>>>>>>                   Could you also include the change which requires to add
>>>>>>>                   some default output screen name to the
>>>>>>>                   getNativeScaleFactor() function on Linux. There is the
>>>>>>>                   discussion about that:
>>>>>>>
>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>>>> h
>>>>>>> t
>>>>>>> m
>>>>>>> l
>>>>>>>
>>>>>>>                   Thanks,
>>>>>>>                   Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                       Thanks,
>>>>>>>                       Alexandr.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                           Regards,
>>>>>>>
>>>>>>>                           Rajeev Chamyal
>>>>>>>


From alexander.zvegintsev at oracle.com  Tue Sep 13 19:14:40 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 13 Sep 2016 22:14:40 +0300
Subject: <AWT Dev> [9] Review request for 8140311: SwingInterop crashes at
	window close
Message-ID: <4229cc49-434f-d21f-e8c8-54ae95037784@oracle.com>

Hello,

please review the fix

http://cr.openjdk.java.net/~azvegint/jdk/9/8140311/00/

for the issue

https://bugs.openjdk.java.net/browse/JDK-8140311

This issue is only reproducible when a window using CWarningWindow.
After window close we cancel HidingTask in CWarningWindow at java level, 
however we do not cancel delayed execution of "perform" selector at 
native level.
At this point cached JNIEnv value becomes invalid, which is leading to 
crash.

-- 
Thanks,
Alexander.


From alexander.zvegintsev at oracle.com  Tue Sep 13 19:29:49 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Tue, 13 Sep 2016 22:29:49 +0300
Subject: <AWT Dev> [9] Review Request: 8004693 TEST_BUG:
 java/awt/KeyboardFocusmanager/DefaultPolicyChange/DefaultPolicyChange_Swing.java
 fails
In-Reply-To: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
References: <eb5fd302-ada9-0032-3560-ce8589797ff0@oracle.com>
Message-ID: <640ee50b-d3ac-0d21-2ef5-19540c748f10@oracle.com>

Looks good to me.


On 5/30/16 7:39 PM, Sergey Bylokhov wrote:
> Hello.
> Please review the fix for jdk9.
>
> The test DefaultPolicyChange_Swing.java has two issues:
>  - It uses invokeLater(), so the test usually pass before the code is 
> executed on the EDT, because the main thread completes before.
>  - The test fetches the FocusTraversalPolicy from the current 
> KeyboardFocusManager. But default FocusTraversalPolicy can be changed 
> during the Swing initialization(JDK-7125044). The test should save the 
> state before setDefaultFocusTraversalPolicy() but after the Swing 
> initialization, and validate that the FocusTraversalPolicy was not 
> changed for windows which were already shown.
>
> The fix proposed in the CR is applied + small cleanup(regtesthelpers 
> removed and InvokeAndWait is used instead of InvokeLater+realSync)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8004693
> Webrev can be found at: 
> http://cr.openjdk.java.net/~serb/8004693/webrev.01
>

-- 
Thanks,
Alexander.


From manajit.halder at oracle.com  Wed Sep 14 11:43:48 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 14 Sep 2016 17:13:48 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8163270: [macosx]
	Robot(gc) issue on dual-screen system.
In-Reply-To: <5aac63b7-3947-8a4a-9a0e-8188238680bc@oracle.com>
References: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>
	<5aac63b7-3947-8a4a-9a0e-8188238680bc@oracle.com>
Message-ID: <6F7DB93C-36CC-412D-826B-1F58A86FC6C7@oracle.com>

Hi Sergey,

Thank you for your review comment. Code is modified and cleaned.
Please review the modified webrev.

http://cr.openjdk.java.net/~mhalder/8163270/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8163270/webrev.01/>

Thanks,
Manajit

> On 09-Sep-2016, at 10:08 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> I recognized that the test can be cleaned a little bit. We can move the code from the init() to main and remove all other unnecessary stuff: TestPassedException, pass(), setTimeoutTo(), etc.
> 
> On 09.09.16 8:23, Manajit Halder wrote:
>> 
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> *Bug*:
>> _https://bugs.openjdk.java.net/browse/JDK-8163270_
>> _
>> _
>> *Webrev*:
>> http://cr.openjdk.java.net/~mhalder/8163270/webrev.00/
>> 
>> *Issue: *
>> [macosx] Robot(gc) issue on dual-screen system.
>> 
>> *Cause: *
>> Calculation of x coordinate value was wrong for the mouse cursor in the
>> extended monitor.
>> 
>> *Fix: *
>> Calculation corrected for x coordinate.
>> 
>> Regards,
>> Manajit
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160914/2c09dee3/attachment-0001.html>

From alexandr.scherbatiy at oracle.com  Wed Sep 14 15:03:01 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Wed, 14 Sep 2016 18:03:01 +0300
Subject: <AWT Dev> [9] fix for JDK-8134612
 :clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for
 registered data flavor
In-Reply-To: <f48f37cb-d80f-4458-9ab6-5b5464ff4971@default>
References: <f48f37cb-d80f-4458-9ab6-5b5464ff4971@default>
Message-ID: <09c47deb-0740-05d3-6a94-ad4711f66930@oracle.com>


On 9/14/2016 1:14 PM, Ajit Ghaisas wrote:
>
> Hi,
>
> Bug : https://bugs.openjdk.java.net/browse/JDK-8134612
>
> Issue :
>
> In this test, exportToClipboard() does not export anything to the 
> clipboard due to incorrect text passed to TransferHandler.
>
> Obviously, when we do clipboard.getData() - it throws 
> UnsupportedFlavorException. This is the root cause.
>
> Also, when text is imported, the text String cannot be assigned to 
> MyStringReader class.
>
> Fix :
>
> The test is corrected to use custom dataflavor containing String to 
> export and import from clipboard.
>
> Also, the test is enhanced to test a custom dataflavor of Color.
>
> I have referred to :
>
> https://docs.oracle.com/javase/tutorial/uiswing/dnd/dataflavor.html
>
> It passes consistently on Windows, Linux and Mac.
>
> Webrev :
>
> http://cr.openjdk.java.net/~aghaisas/8134612/webrev.00/
>
> Request you to review.
>
   - The test has been designed to check that the reflection in 
DataTransferer.constructFlavoredObject() method properly works with the 
modularization system.
   Could the test be updated  to call  the 
DataTransferer.constructFlavoredObject() method which creates an object 
using flavor.getRepresentationClass() constructor?

  - I also resent the email to the awt-dev alias.

   Thanks,
   Alexandr.
>
> Regards,
>
> Ajit
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160914/44dc90d8/attachment.html>

From Sergey.Bylokhov at oracle.com  Wed Sep 14 15:35:28 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Sep 2016 18:35:28 +0300
Subject: <AWT Dev> [9] Review Request: 8165717 Various memory leaks in jdk9
Message-ID: <0dcb4732-aab8-fd07-c7bc-c1c444e1726b@oracle.com>

Hello.

Please review the small fix for jdk9. Note that I plan to backport it to 
jdk8:

NSApplicationAWT class have a special method which posts event to the 
native queue. This event is used to execute the block of code which 
contains CFRelease for some native resource. It was implemented in this 
way (instead of simple "performOnmMainThread") because we should filter 
this event when the nested native loop is active. The problem is that 
this method overretain the block. [block copy] copy the block from the 
stack and retain it(or just retain if the block is in memory already), 
and since we retain it again we get a memory leak, because we release it 
only once in NSApplicationAWT.sendEvent(). The leak is quite small but 
the code can be executed lots of time which cause allocation of 
unreasonable amount of memory. There is no test since the leak is 
native, and it will be necessary to spend lots of time to fill the whole 
native memory and swap.

The bug was found when I worked on 'other fix', and some other memory 
leaks will be fixed separately in 'other fix'.

Bug: https://bugs.openjdk.java.net/browse/JDK-8165717
Patch can be found at: http://cr.openjdk.java.net/~serb/8165717/webrev.00

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Wed Sep 14 16:25:55 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Sep 2016 19:25:55 +0300
Subject: <AWT Dev> [9] Review request for 8140311: SwingInterop crashes
 at window close
In-Reply-To: <4229cc49-434f-d21f-e8c8-54ae95037784@oracle.com>
References: <4229cc49-434f-d21f-e8c8-54ae95037784@oracle.com>
Message-ID: <cb841add-74ee-fce9-2c90-81b182992f6f@oracle.com>

Looks fine.

On 13.09.16 22:14, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8140311/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8140311
>
> This issue is only reproducible when a window using CWarningWindow.
> After window close we cancel HidingTask in CWarningWindow at java level,
> however we do not cancel delayed execution of "perform" selector at
> native level.
> At this point cached JNIEnv value becomes invalid, which is leading to
> crash.
>


-- 
Best regards, Sergey.

From ambarish.rapte at oracle.com  Wed Sep 14 16:56:46 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Wed, 14 Sep 2016 09:56:46 -0700 (PDT)
Subject: <AWT Dev> Review request for 8162102: New access restriction
 awt.robot.gtk: what to fix?
Message-ID: <68fd0af1-da87-42ef-8b13-c1b56d3e1b5c@default>

Hi,

                Please review this fix for JDK9,

                Webrev: http://cr.openjdk.java.net/~arapte/8162102/webrev.00/

                Bug: https://bugs.openjdk.java.net/browse/JDK-8162102

 

Issue:

                "java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java"  Test fails with 

Exception java.security.AccessControlException: access denied ("java.util.PropertyPermission" "awt.robot.gtk" "read")

All tests using security policy would fail with same exception.

 

Cause:

                Issue occurs when only a security policy is used.

                System property  awt.robot.gtk  accessing was added as fix of https://bugs.openjdk.java.net/browse/JDK-8150954

Discussion mail: http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010999.html

 

Fix:

                Added the getBoolean call inside a privileged block.

                

 

Regards,

Ambarish

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

From semyon.sadetsky at oracle.com  Wed Sep 14 17:07:03 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 14 Sep 2016 20:07:03 +0300
Subject: <AWT Dev> Review request for 8162102: New access restriction
 awt.robot.gtk: what to fix?
In-Reply-To: <68fd0af1-da87-42ef-8b13-c1b56d3e1b5c@default>
References: <68fd0af1-da87-42ef-8b13-c1b56d3e1b5c@default>
Message-ID: <74f2bec7-90e0-d150-5b3e-27e85d81eaba@oracle.com>

Looks good.

--Semyon


On 9/14/2016 7:56 PM, Ambarish Rapte wrote:
>
> Hi,
>
>                 Please review this fix for JDK9,
>
>                 Webrev: 
> http://cr.openjdk.java.net/~arapte/8162102/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/8162102/webrev.00/>
>
>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8162102
>
> Issue:
>
>                 
> ?/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java/" 
>  Test fails with
>
> Exception /java.security.AccessControlException: access denied 
> ("java.util.PropertyPermission" "awt.robot.gtk" "read")/
>
> All tests using security policy would fail with same exception.
>
> Cause:
>
>                 Issue occurs when only a security policy is used.
>
>                 System property /awt.robot.gtk/  accessing was added 
> as fix of https://bugs.openjdk.java.net/browse/JDK-8150954
>
> Discussion mail: 
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010999.html
>
> Fix:
>
>                 Added the getBoolean call inside a privileged block.
>
> Regards,
>
> Ambarish
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160914/6892ab86/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Wed Sep 14 17:34:10 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Sep 2016 20:34:10 +0300
Subject: <AWT Dev> Review request for 8162102: New access restriction
 awt.robot.gtk: what to fix?
In-Reply-To: <74f2bec7-90e0-d150-5b3e-27e85d81eaba@oracle.com>
References: <68fd0af1-da87-42ef-8b13-c1b56d3e1b5c@default>
	<74f2bec7-90e0-d150-5b3e-27e85d81eaba@oracle.com>
Message-ID: <65a3a240-f904-47a7-ec4a-0dae6d16fea0@oracle.com>

+1, but please rename the title of the bug to some better text, right 
now "what to fix?" looks cryptic.

On 14.09.16 20:07, Semyon Sadetsky wrote:
> Looks good.
>
> --Semyon
>
>
> On 9/14/2016 7:56 PM, Ambarish Rapte wrote:
>>
>> Hi,
>>
>>                 Please review this fix for JDK9,
>>
>>                 Webrev:
>> http://cr.openjdk.java.net/~arapte/8162102/webrev.00/
>> <http://cr.openjdk.java.net/%7Earapte/8162102/webrev.00/>
>>
>>                 Bug: https://bugs.openjdk.java.net/browse/JDK-8162102
>>
>>
>>
>> Issue:
>>
>>
>> ?/java/awt/AppContext/ApplicationThreadsStop/ApplicationThreadsStop.java/"
>>  Test fails with
>>
>> Exception /java.security.AccessControlException: access denied
>> ("java.util.PropertyPermission" "awt.robot.gtk" "read")/
>>
>> All tests using security policy would fail with same exception.
>>
>>
>>
>> Cause:
>>
>>                 Issue occurs when only a security policy is used.
>>
>>                 System property  /awt.robot.gtk/  accessing was added
>> as fix of https://bugs.openjdk.java.net/browse/JDK-8150954
>>
>> Discussion mail:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-April/010999.html
>>
>>
>>
>> Fix:
>>
>>                 Added the getBoolean call inside a privileged block.
>>
>>
>>
>>
>>
>> Regards,
>>
>> Ambarish
>>
>>
>>
>


-- 
Best regards, Sergey.

From Alan.Burlison at oracle.com  Wed Sep 14 17:42:22 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Wed, 14 Sep 2016 18:42:22 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
Message-ID: <246e1014-6227-a00a-6464-450ccab63e37@oracle.com>

On 06/09/2016 11:16, Alan Burlison wrote:

> XKeycodeToKeysym is deprecated and when compiled on Solaris 12 with
> warnings-as-errors this causes a compile time failure. References to
> XKeycodeToKeysym should be replaced by XkbKeycodeToKeysym. As this is
> common XOrg code it will affect Linux as well.
>
> Bug:    https://bugs.openjdk.java.net/browse/JDK-8165232
> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165232/

I've respun this and replaced the calls to XKeycodeToKeysym with 
equivalent code that uses XGetKeyboardMapping instead. This addresses 
the problem without introducing a dependency on XKEYBOARD, which I think 
is is a better fix.

I'd appreciate any review comments.

Thanks,

-- 
Alan Burlison
--

From Sergey.Bylokhov at oracle.com  Wed Sep 14 18:07:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 14 Sep 2016 21:07:41 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8163270: [macosx]
 Robot(gc) issue on dual-screen system.
In-Reply-To: <6F7DB93C-36CC-412D-826B-1F58A86FC6C7@oracle.com>
References: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>
	<5aac63b7-3947-8a4a-9a0e-8188238680bc@oracle.com>
	<6F7DB93C-36CC-412D-826B-1F58A86FC6C7@oracle.com>
Message-ID: <5d1736bb-5e99-3550-6883-1d4e40ba80fd@oracle.com>

Looks fine, thanks!

On 14.09.16 14:43, Manajit Halder wrote:
> Hi Sergey,
>
> Thank you for your review comment. Code is modified and cleaned.
> Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8163270/webrev.01/
>
> Thanks,
> Manajit
>
>> On 09-Sep-2016, at 10:08 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> I recognized that the test can be cleaned a little bit. We can move
>> the code from the init() to main and remove all other unnecessary
>> stuff: TestPassedException, pass(), setTimeoutTo(), etc.
>>
>> On 09.09.16 8:23, Manajit Halder wrote:
>>>
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>>
>>> *Bug*:
>>> _https://bugs.openjdk.java.net/browse/JDK-8163270_
>>> _
>>> _
>>> *Webrev*:
>>> http://cr.openjdk.java.net/~mhalder/8163270/webrev.00/
>>>
>>> *Issue: *
>>> [macosx] Robot(gc) issue on dual-screen system.
>>>
>>> *Cause: *
>>> Calculation of x coordinate value was wrong for the mouse cursor in the
>>> extended monitor.
>>>
>>> *Fix: *
>>> Calculation corrected for x coordinate.
>>>
>>> Regards,
>>> Manajit
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From ajit.ghaisas at oracle.com  Thu Sep 15 05:20:44 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 14 Sep 2016 22:20:44 -0700 (PDT)
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8163270: [macosx]
 Robot(gc) issue on dual-screen system.
In-Reply-To: <5d1736bb-5e99-3550-6883-1d4e40ba80fd@oracle.com>
References: <71E852F0-4172-4FC4-9E9B-1B7CFA22ECE3@oracle.com>
	<5aac63b7-3947-8a4a-9a0e-8188238680bc@oracle.com>
	<6F7DB93C-36CC-412D-826B-1F58A86FC6C7@oracle.com>
	<5d1736bb-5e99-3550-6883-1d4e40ba80fd@oracle.com>
Message-ID: <a69806f5-a88c-480a-b5be-35eef11f4717@default>

Test looks good after suggested cleanup.

Regards,
Ajit

-----Original Message-----
From: Sergey Bylokhov 
Sent: Wednesday, September 14, 2016 11:38 PM
To: Manajit Halder
Cc: Rajeev Chamyal; Ajit Ghaisas; awt-dev at openjdk.java.net
Subject: Re: <AWT dev>[9] Review request for JDK-8163270: [macosx] Robot(gc) issue on dual-screen system.

Looks fine, thanks!

On 14.09.16 14:43, Manajit Halder wrote:
> Hi Sergey,
>
> Thank you for your review comment. Code is modified and cleaned.
> Please review the modified webrev.
>
> http://cr.openjdk.java.net/~mhalder/8163270/webrev.01/
>
> Thanks,
> Manajit
>
>> On 09-Sep-2016, at 10:08 pm, Sergey Bylokhov 
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> I recognized that the test can be cleaned a little bit. We can move 
>> the code from the init() to main and remove all other unnecessary
>> stuff: TestPassedException, pass(), setTimeoutTo(), etc.
>>
>> On 09.09.16 8:23, Manajit Halder wrote:
>>>
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>>
>>> *Bug*:
>>> _https://bugs.openjdk.java.net/browse/JDK-8163270_
>>> _
>>> _
>>> *Webrev*:
>>> http://cr.openjdk.java.net/~mhalder/8163270/webrev.00/
>>>
>>> *Issue: *
>>> [macosx] Robot(gc) issue on dual-screen system.
>>>
>>> *Cause: *
>>> Calculation of x coordinate value was wrong for the mouse cursor in 
>>> the extended monitor.
>>>
>>> *Fix: *
>>> Calculation corrected for x coordinate.
>>>
>>> Regards,
>>> Manajit
>>
>>
>> --
>> Best regards, Sergey.
>


--
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Thu Sep 15 08:08:06 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 15 Sep 2016 11:08:06 +0300
Subject: <AWT Dev> [9] Review Request: 8165717 Various memory leaks in
 jdk9
In-Reply-To: <0dcb4732-aab8-fd07-c7bc-c1c444e1726b@oracle.com>
References: <0dcb4732-aab8-fd07-c7bc-c1c444e1726b@oracle.com>
Message-ID: <2e554f55-895f-1b53-d379-406b35707630@jetbrains.com>

Hi Sergey,

The fix looks correct to me.

On 9/14/2016 6:35 PM, Sergey Bylokhov wrote:
> Hello.
>
> Please review the small fix for jdk9. Note that I plan to backport it 
> to jdk8:
That would be really good, thanks!

Regards,
Anton.

>
> NSApplicationAWT class have a special method which posts event to the 
> native queue. This event is used to execute the block of code which 
> contains CFRelease for some native resource. It was implemented in 
> this way (instead of simple "performOnmMainThread") because we should 
> filter this event when the nested native loop is active. The problem 
> is that this method overretain the block. [block copy] copy the block 
> from the stack and retain it(or just retain if the block is in memory 
> already), and since we retain it again we get a memory leak, because 
> we release it only once in NSApplicationAWT.sendEvent(). The leak is 
> quite small but the code can be executed lots of time which cause 
> allocation of unreasonable amount of memory. There is no test since 
> the leak is native, and it will be necessary to spend lots of time to 
> fill the whole native memory and swap.
>
> The bug was found when I worked on 'other fix', and some other memory 
> leaks will be fixed separately in 'other fix'.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8165717
> Patch can be found at: http://cr.openjdk.java.net/~serb/8165717/webrev.00
>


From semyon.sadetsky at oracle.com  Thu Sep 15 09:43:02 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 15 Sep 2016 12:43:02 +0300
Subject: <AWT Dev> [9] Review Request: 8165717 Various memory leaks in
 jdk9
In-Reply-To: <2e554f55-895f-1b53-d379-406b35707630@jetbrains.com>
References: <0dcb4732-aab8-fd07-c7bc-c1c444e1726b@oracle.com>
	<2e554f55-895f-1b53-d379-406b35707630@jetbrains.com>
Message-ID: <69797aeb-cb19-7333-d59b-846bd07175ae@oracle.com>

+1

--Semyon


On 15.09.2016 11:08, Anton Tarasov wrote:
> Hi Sergey,
>
> The fix looks correct to me.
>
> On 9/14/2016 6:35 PM, Sergey Bylokhov wrote:
>> Hello.
>>
>> Please review the small fix for jdk9. Note that I plan to backport it 
>> to jdk8:
> That would be really good, thanks!
>
> Regards,
> Anton.
>
>>
>> NSApplicationAWT class have a special method which posts event to the 
>> native queue. This event is used to execute the block of code which 
>> contains CFRelease for some native resource. It was implemented in 
>> this way (instead of simple "performOnmMainThread") because we should 
>> filter this event when the nested native loop is active. The problem 
>> is that this method overretain the block. [block copy] copy the block 
>> from the stack and retain it(or just retain if the block is in memory 
>> already), and since we retain it again we get a memory leak, because 
>> we release it only once in NSApplicationAWT.sendEvent(). The leak is 
>> quite small but the code can be executed lots of time which cause 
>> allocation of unreasonable amount of memory. There is no test since 
>> the leak is native, and it will be necessary to spend lots of time to 
>> fill the whole native memory and swap.
>>
>> The bug was found when I worked on 'other fix', and some other memory 
>> leaks will be fixed separately in 'other fix'.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8165717
>> Patch can be found at: 
>> http://cr.openjdk.java.net/~serb/8165717/webrev.00
>>
>


From anton.tarasov at jetbrains.com  Thu Sep 15 09:45:11 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 15 Sep 2016 12:45:11 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x crashes
	with NPE at
	sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
Message-ID: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>

Hello,

Please review the fix:

bug: https://bugs.openjdk.java.net/browse/JDK-8165829 <https://bugs.openjdk.java.net/browse/JDK-8165829>
webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0 <http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0>

(The bug is currently closed as ?not an issue?, which is not quite true. So once and if the fix is approved I can take the ownership of the bug).

The problem is this. Sometimes when a frame is closed there may appear a race condition:

- removeNotify() is called on the frame on EDT and it removes all the events associated with the frame from the event queue.

- The frame is requested by accessibility via the CAccessibility static methods (like CAccessibility.getAccessibleIndexInParent). Those methods are called from native on AppKit thread and they perform via invokeAndWait. The latter is wrapped with an InvocationEvent whose source is set to the frame. But, once the event is put on the event queue, it's purged by the removeNotify() call. As the result, invokeAndWait returns null. Then, in some of the mentioned methods 'null' is unboxed to a primitive 'int' or 'boolean' which results in NPE propagated to native. On the native side, the NPE is not properly handled and is just re-thrown.

I don't have a simple and safe solution for the race. So, I suggest to fix the NPE/crash at least.

Thanks,
Anton.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160915/36e9d8a3/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Thu Sep 15 09:59:42 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Sep 2016 12:59:42 +0300
Subject: <AWT Dev> [9] Review Request JDK-8149371 multi-res. image:
 -Dsun.java2d.uiScale does not work for Window icons (some ambiguity for
 Window.setIconImages
In-Reply-To: <11684527-6733-c11d-4398-c7fbaa99e5ed@oracle.com>
References: <561f53f2-fb67-4a2d-96ae-e9ed3ead5bf8@default>
	<4e4ab82e-60fd-bd7b-dec3-1a02478c79e6@oracle.com>
	<48e010c5-f33b-4101-abef-b89de1a9f94b@default>
	<11684527-6733-c11d-4398-c7fbaa99e5ed@oracle.com>
Message-ID: <a9ee349d-9344-b3a5-4a4c-f374b7f53dab@oracle.com>

+1

On 06.09.16 13:50, Alexandr Scherbatiy wrote:
> The fix looks good to me.
>
> Thanks,
> Alexandr.
>
> On 9/6/2016 1:30 PM, Rajeev Chamyal wrote:
>>
>> Hello Alexander,
>>
>>
>>
>> Thanks for the review.I have updated webrev as per review comments.
>>
>> http://cr.openjdk.java.net/~rchamyal/8149371/webrev.01/
>> <http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.01/>
>>
>>
>>
>> Regards,
>>
>> Rajeev Chamyal
>>
>>
>>
>> *From:*Alexandr Scherbatiy
>> *Sent:* 05 September 2016 16:04
>> *To:* Rajeev Chamyal; Sergey Bylokhov; awt-dev at openjdk.java.net
>> *Subject:* Re: <AWT Dev>[9] Review Request JDK-8149371 multi-res.
>> image: -Dsun.java2d.uiScale does not work for Window icons (some
>> ambiguity for Window.setIconImages
>>
>>
>>
>> On 9/2/2016 2:37 PM, Rajeev Chamyal wrote:
>>
>>     Hello All,
>>
>>
>>
>>     Please review the following webrev.
>>
>>
>>
>>     Bug: https://bugs.openjdk.java.net/browse/JDK-8149371
>>
>>     Webrev: http://cr.openjdk.java.net/~rchamyal/8149371/webrev.00/
>>     <http://cr.openjdk.java.net/%7Erchamyal/8149371/webrev.00/>
>>
>>
>>
>>     Issue: Multiresolution icons are not working with
>>     -Dsun.java2d.uiScale.
>>
>>     Fix: Updated the implementation of SunToolkit:getScaledIconImage
>>      to extract appropriate Multiresolution image and consider it in
>>     the existing algorithm for finding best image.
>>
>>     Java doc for Window:setIconImages is also updated.
>>
>>   - It is possible to use only one ArrayList which initial size is
>> number of images in the image list. Iterating over image list we can
>> add to the array list an initial image if it is not instance of
>> MultiResolutionImage or a resolution variant.
>>   - Is it required that images in the imageList are sorted?
>>   - It is better to reuse the dpi values in the awt_Window.cpp file
>> (see fix for issue JDK-8158411)
>>
>>   Thanks,
>>   Alexandr.
>>
>>
>>
>>
>>     Regards,
>>
>>     Rajeev Chamyal
>>
>>
>>
>>
>>
>


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Thu Sep 15 10:21:43 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 15 Sep 2016 13:21:43 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
Message-ID: <f119f5b3-7973-7b01-87cd-0e91af66ab04@jetbrains.com>

On 9/15/2016 12:45 PM, Anton Tarasov wrote:
> Hello,
>
> Please review the fix:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0 
> <http://cr.openjdk.java.net/%7Eant/JDK-8165829/jdk9/webrev.0>
>
> (The bug is currently closed as ?not an issue?, which is not quite 
> true. So once and if the fix is approved I can take the ownership of 
> the bug).
>
> The problem is this. Sometimes when a frame is closed there may appear 
> a race condition:
>
> - removeNotify() is called on the frame on EDT and it removes all the 
> events associated with the frame from the event queue.
>
> - The frame is requested by accessibility via the CAccessibility 
> static methods (like CAccessibility.getAccessibleIndexInParent). Those 
> methods are called from native on AppKit thread and they perform via 
> invokeAndWait. The latter is wrapped with an InvocationEvent whose 
> source is set to the frame. But, once the event is put on the event 
> queue, it's purged by the removeNotify() call. As the result, 
> invokeAndWait returns null. Then, in some of the mentioned methods 
> 'null' is unboxed to a primitive 'int' or 'boolean' which results in 
> NPE propagated to native. On the native side, the NPE is not properly 
> handled and is just re-thrown.

I forgot to add, as a comment to the fix, that createWithAccessible() is 
ok to return nil, it's checked.

Anton.

>
> I don't have a simple and safe solution for the race. So, I suggest to 
> fix the NPE/crash at least.
>
> Thanks,
> Anton.
>
>


From Sergey.Bylokhov at oracle.com  Thu Sep 15 10:28:05 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Sep 2016 13:28:05 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
Message-ID: <9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>

Why not all methods in CAccessibility are updated? For example what is 
the difference between	getAccessibleIndexInParent and 
getAccessibleParent? I think that it will be strange if 
getLocationOnScreen() will return null? Probably the old 
invokeAndWait(Callable,Component)  should be updated to use this def value?

On 15.09.16 12:45, Anton Tarasov wrote:
> Hello,
>
> Please review the fix:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>
> (The bug is currently closed as ?not an issue?, which is not quite true.
> So once and if the fix is approved I can take the ownership of the bug).
>
> The problem is this. Sometimes when a frame is closed there may appear a
> race condition:
>
> - removeNotify() is called on the frame on EDT and it removes all the
> events associated with the frame from the event queue.
>
> - The frame is requested by accessibility via the CAccessibility static
> methods (like CAccessibility.getAccessibleIndexInParent). Those methods
> are called from native on AppKit thread and they perform via
> invokeAndWait. The latter is wrapped with an InvocationEvent whose
> source is set to the frame. But, once the event is put on the event
> queue, it's purged by the removeNotify() call. As the result,
> invokeAndWait returns null. Then, in some of the mentioned methods
> 'null' is unboxed to a primitive 'int' or 'boolean' which results in NPE
> propagated to native. On the native side, the NPE is not properly
> handled and is just re-thrown.
>
> I don't have a simple and safe solution for the race. So, I suggest to
> fix the NPE/crash at least.
>
> Thanks,
> Anton.
>
>


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Thu Sep 15 10:38:04 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 15 Sep 2016 13:38:04 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
Message-ID: <69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>

Hi Sergey,

On 9/15/2016 1:28 PM, Sergey Bylokhov wrote:
> Why not all methods in CAccessibility are updated? For example what is 
> the difference between getAccessibleIndexInParent and getAccessibleParent?

The difference is that getAccessibleParent may return "null" to native 
which is expected and handled, whereas getAccessibleIndexInParent may 
throw NPE which is unexpected and not handled.
The problem occurs when unboxing null to a primitive wrapper 
(Integer/Boolean etc). I've changed only those methods.

> I think that it will be strange if getLocationOnScreen() will return 
> null? Probably the old invokeAndWait(Callable,Component)  should be 
> updated to use this def value?

The new invokeAndWait returns _requested_ default value which seems 
better in general.

Anton.

>
> On 15.09.16 12:45, Anton Tarasov wrote:
>> Hello,
>>
>> Please review the fix:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>
>> (The bug is currently closed as ?not an issue?, which is not quite true.
>> So once and if the fix is approved I can take the ownership of the bug).
>>
>> The problem is this. Sometimes when a frame is closed there may appear a
>> race condition:
>>
>> - removeNotify() is called on the frame on EDT and it removes all the
>> events associated with the frame from the event queue.
>>
>> - The frame is requested by accessibility via the CAccessibility static
>> methods (like CAccessibility.getAccessibleIndexInParent). Those methods
>> are called from native on AppKit thread and they perform via
>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>> source is set to the frame. But, once the event is put on the event
>> queue, it's purged by the removeNotify() call. As the result,
>> invokeAndWait returns null. Then, in some of the mentioned methods
>> 'null' is unboxed to a primitive 'int' or 'boolean' which results in NPE
>> propagated to native. On the native side, the NPE is not properly
>> handled and is just re-thrown.
>>
>> I don't have a simple and safe solution for the race. So, I suggest to
>> fix the NPE/crash at least.
>>
>> Thanks,
>> Anton.
>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Thu Sep 15 10:50:18 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 15 Sep 2016 13:50:18 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
Message-ID: <594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>

On 15.09.16 13:38, Anton Tarasov wrote:
> The difference is that getAccessibleParent may return "null" to native
> which is expected and handled, whereas getAccessibleIndexInParent may
> throw NPE which is unexpected and not handled.
> The problem occurs when unboxing null to a primitive wrapper
> (Integer/Boolean etc). I've changed only those methods.
>
>> I think that it will be strange if getLocationOnScreen() will return
>> null? Probably the old invokeAndWait(Callable,Component)  should be
>> updated to use this def value?
>
> The new invokeAndWait returns _requested_ default value which seems
> better in general.

Yes, and my suggestion was to use the new method and default values 
everywhere instead of invokeAndWait(Callable,Component).

>>
>> On 15.09.16 12:45, Anton Tarasov wrote:
>>> Hello,
>>>
>>> Please review the fix:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>
>>> (The bug is currently closed as ?not an issue?, which is not quite true.
>>> So once and if the fix is approved I can take the ownership of the bug).
>>>
>>> The problem is this. Sometimes when a frame is closed there may appear a
>>> race condition:
>>>
>>> - removeNotify() is called on the frame on EDT and it removes all the
>>> events associated with the frame from the event queue.
>>>
>>> - The frame is requested by accessibility via the CAccessibility static
>>> methods (like CAccessibility.getAccessibleIndexInParent). Those methods
>>> are called from native on AppKit thread and they perform via
>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>> source is set to the frame. But, once the event is put on the event
>>> queue, it's purged by the removeNotify() call. As the result,
>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results in NPE
>>> propagated to native. On the native side, the NPE is not properly
>>> handled and is just re-thrown.
>>>
>>> I don't have a simple and safe solution for the race. So, I suggest to
>>> fix the NPE/crash at least.
>>>
>>> Thanks,
>>> Anton.
>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Thu Sep 15 11:48:28 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Thu, 15 Sep 2016 14:48:28 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
Message-ID: <e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>

On 9/15/2016 1:50 PM, Sergey Bylokhov wrote:

> On 15.09.16 13:38, Anton Tarasov wrote:
>> The difference is that getAccessibleParent may return "null" to native
>> which is expected and handled, whereas getAccessibleIndexInParent may
>> throw NPE which is unexpected and not handled.
>> The problem occurs when unboxing null to a primitive wrapper
>> (Integer/Boolean etc). I've changed only those methods.
>>
>>> I think that it will be strange if getLocationOnScreen() will return
>>> null? Probably the old invokeAndWait(Callable,Component) should be
>>> updated to use this def value?
>>
>> The new invokeAndWait returns _requested_ default value which seems
>> better in general.
>
> Yes, and my suggestion was to use the new method and default values 
> everywhere instead of invokeAndWait(Callable,Component).

But the default value for a reference would be null, there's no need to 
request something else, unlike for primitive wrappers.

Or your idea is to force passing a def value anyway?

Anton.

>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>> Hello,
>>>>
>>>> Please review the fix:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>
>>>> (The bug is currently closed as ?not an issue?, which is not quite 
>>>> true.
>>>> So once and if the fix is approved I can take the ownership of the 
>>>> bug).
>>>>
>>>> The problem is this. Sometimes when a frame is closed there may 
>>>> appear a
>>>> race condition:
>>>>
>>>> - removeNotify() is called on the frame on EDT and it removes all the
>>>> events associated with the frame from the event queue.
>>>>
>>>> - The frame is requested by accessibility via the CAccessibility 
>>>> static
>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those 
>>>> methods
>>>> are called from native on AppKit thread and they perform via
>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>> source is set to the frame. But, once the event is put on the event
>>>> queue, it's purged by the removeNotify() call. As the result,
>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results 
>>>> in NPE
>>>> propagated to native. On the native side, the NPE is not properly
>>>> handled and is just re-thrown.
>>>>
>>>> I don't have a simple and safe solution for the race. So, I suggest to
>>>> fix the NPE/crash at least.
>>>>
>>>> Thanks,
>>>> Anton.
>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 16 10:32:26 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 16 Sep 2016 13:32:26 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
	<e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
Message-ID: <ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>

On 15.09.16 14:48, Anton Tarasov wrote:
>> Yes, and my suggestion was to use the new method and default values
>> everywhere instead of invokeAndWait(Callable,Component).
>
> But the default value for a reference would be null, there's no need to
> request something else, unlike for primitive wrappers.
>
> Or your idea is to force passing a def value anyway?

If the references like Point from getLocationOnScreen() can be null, 
then ok. looks fine.

>
> Anton.
>
>>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>>
>>>>> (The bug is currently closed as ?not an issue?, which is not quite
>>>>> true.
>>>>> So once and if the fix is approved I can take the ownership of the
>>>>> bug).
>>>>>
>>>>> The problem is this. Sometimes when a frame is closed there may
>>>>> appear a
>>>>> race condition:
>>>>>
>>>>> - removeNotify() is called on the frame on EDT and it removes all the
>>>>> events associated with the frame from the event queue.
>>>>>
>>>>> - The frame is requested by accessibility via the CAccessibility
>>>>> static
>>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those
>>>>> methods
>>>>> are called from native on AppKit thread and they perform via
>>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>>> source is set to the frame. But, once the event is put on the event
>>>>> queue, it's purged by the removeNotify() call. As the result,
>>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results
>>>>> in NPE
>>>>> propagated to native. On the native side, the NPE is not properly
>>>>> handled and is just re-thrown.
>>>>>
>>>>> I don't have a simple and safe solution for the race. So, I suggest to
>>>>> fix the NPE/crash at least.
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Fri Sep 16 17:49:37 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Fri, 16 Sep 2016 20:49:37 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
	<e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
	<ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>
Message-ID: <bd326ed9-f58b-0473-97e8-92bd4218f749@jetbrains.com>

On 9/16/2016 1:32 PM, Sergey Bylokhov wrote:
> On 15.09.16 14:48, Anton Tarasov wrote:
>>> Yes, and my suggestion was to use the new method and default values
>>> everywhere instead of invokeAndWait(Callable,Component).
>>
>> But the default value for a reference would be null, there's no need to
>> request something else, unlike for primitive wrappers.
>>
>> Or your idea is to force passing a def value anyway?
>
> If the references like Point from getLocationOnScreen() can be null, 
> then ok. looks fine.

Yes, it can.

Anton.

>
>>
>> Anton.
>>
>>>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix:
>>>>>>
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>>>
>>>>>> (The bug is currently closed as ?not an issue?, which is not quite
>>>>>> true.
>>>>>> So once and if the fix is approved I can take the ownership of the
>>>>>> bug).
>>>>>>
>>>>>> The problem is this. Sometimes when a frame is closed there may
>>>>>> appear a
>>>>>> race condition:
>>>>>>
>>>>>> - removeNotify() is called on the frame on EDT and it removes all 
>>>>>> the
>>>>>> events associated with the frame from the event queue.
>>>>>>
>>>>>> - The frame is requested by accessibility via the CAccessibility
>>>>>> static
>>>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those
>>>>>> methods
>>>>>> are called from native on AppKit thread and they perform via
>>>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>>>> source is set to the frame. But, once the event is put on the event
>>>>>> queue, it's purged by the removeNotify() call. As the result,
>>>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results
>>>>>> in NPE
>>>>>> propagated to native. On the native side, the NPE is not properly
>>>>>> handled and is just re-thrown.
>>>>>>
>>>>>> I don't have a simple and safe solution for the race. So, I 
>>>>>> suggest to
>>>>>> fix the NPE/crash at least.
>>>>>>
>>>>>> Thanks,
>>>>>> Anton.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>


From alexander.zvegintsev at oracle.com  Mon Sep 19 10:18:49 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 19 Sep 2016 13:18:49 +0300
Subject: <AWT Dev> [9] Review request for 8161910: [PIT] regression:
 HW/LW mixing seems broken on Unity
In-Reply-To: <ebce0e99-075c-a685-945d-839d51b5acbb@oracle.com>
References: <65b51ffb-cdbb-2ca1-c3b0-83b90b33e5d5@oracle.com>
	<83e3c1a9-128a-a13a-a486-8101952b3763@oracle.com>
	<ebce0e99-075c-a685-945d-839d51b5acbb@oracle.com>
Message-ID: <3f58b55c-6c6d-19e0-805c-ec53bcba77e9@oracle.com>

Looks good to me.


On 8/30/16 7:18 PM, Semyon Sadetsky wrote:
> Sorry for inconvenience, but I have to update this fix once again.
>
> http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.02
>
> I have found the main root cause of the issue. In the 8036815 I have 
> missed one insets_corrected = true; statement  in the RaparentNotify 
> handler. In my new Unity algo for establishing frame dimensions the 
> insets correction should be postponed until the frame extent property 
> is set. This is corrected in the updated fix.
>
> Also the frame insets correction optimization is restored with only 
> one exclusion when the client area is not set to ensure that the 
> target frame will receive the final size and location update.
>
> --Semyon
>
>
> On 8/24/2016 4:24 PM, Semyon Sadetsky wrote:
>> The fix was amended to 
>> http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.01/
>>
>> Because Unity WM may change initial window location (for example when 
>> window overlaps desktop bars) I removed the optimization that skipped 
>> frame bounds revalidation in case of the initial frame insets was 
>> correct. This should guaranty the ConfigureNotify event always to 
>> come after the extent size event.
>>
>> --Semyon
>>
>> On 8/22/2016 9:19 PM, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8161910
>>>
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8161910/webrev.00/
>>>
>>> A regression of the 8036915 in which a new frame dimensioning algo 
>>> was introduced for the Unity WM because the latter differs from 
>>> other WMs a lot.  The algo has a flaw in some scenarios when the 
>>> extent size event is delayed while the initial frame insets were 
>>> established correctly, therefore the frame dimensions do not require 
>>> any tuning. In this case the content window need to be notified 
>>> right in the extent event handler to let the content to receive its 
>>> new dimensions because subsequent XConfigureNotify event may be 
>>> omitted.
>>>
>>> --Semyon
>>>
>>>
>>
>

-- 
Thanks,
Alexander.


From ambarish.rapte at oracle.com  Mon Sep 19 10:44:58 2016
From: ambarish.rapte at oracle.com (Ambarish Rapte)
Date: Mon, 19 Sep 2016 03:44:58 -0700 (PDT)
Subject: <AWT Dev> Review request for JDK-8166015: [PIT][TEST_BUG] stray
 character in
 java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java
Message-ID: <a2151502-3e85-4dfb-8db3-b9d2693b9956@default>

Hi,

 

Please review this test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8166015

 

 

Issue:    An unwanted character causes compiler error.

Fix:         Removed the character & did few small corrections as guidelines.

 

 

Regards,

Ambarish

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/f5e08f39/attachment.html>

From alexander.zvegintsev at oracle.com  Mon Sep 19 10:49:34 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Mon, 19 Sep 2016 13:49:34 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8041519: JVM crash
 on second DnD after modal dialog opened during Swing DnD operation
In-Reply-To: <55A92CE0.70307@oracle.com>
References: <55A92CE0.70307@oracle.com>
Message-ID: <70f29637-eca0-eed8-6270-e0ebe2afeddf@oracle.com>

Looks good to me.


On 7/17/15 7:27 PM, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
> bug: https://bugs.openjdk.java.net/browse/JDK-8041519
> webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
>
> This is regression from JDK-6342381. When a modal dialog blocks drop 
> operation in progress state consequent mouse events clear the drop 
> context variables (this clearing was introduced by JDK-6342381). The 
> solution is to avoid clearing if drop operation is in progress.
> Test scenario for this case would be too hard and unstable. Since the 
> fix is pretty simple I left it as noreg.
>
> --Semyon
>
>

-- 
Thanks,
Alexander.


From manajit.halder at oracle.com  Mon Sep 19 12:26:02 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Mon, 19 Sep 2016 17:56:02 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx] VM
	crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
Message-ID: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>

Hi All,

Kindly review the fix for JDK9.

Bug: 
https://bugs.openjdk.java.net/browse/JDK-8165555 <https://bugs.openjdk.java.net/browse/JDK-8165555>

Webrev: 
http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/>

Issue: 
[macosx] VM crashes on second attempt to execute JCK interactive tests that use Robot (single JVM, agent)

Cause: 
While executing the JCK test for the second time the robot was getting initialised once again and old instance of CRobotKeyCodeMapping was not available.
Crash was observed while trying to access invalid instance of CRobotKeyCodeMapping.

Fix: 
A new instance of CRobotKeyCodeMapping is created when robot is initialised.

Regards,
Manajit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/702333d7/attachment-0001.html>

From ajit.ghaisas at oracle.com  Mon Sep 19 12:32:36 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Mon, 19 Sep 2016 05:32:36 -0700 (PDT)
Subject: <AWT Dev> Review request for JDK-8166015: [PIT][TEST_BUG] stray
 character in
 java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java
In-Reply-To: <a2151502-3e85-4dfb-8db3-b9d2693b9956@default>
References: <a2151502-3e85-4dfb-8db3-b9d2693b9956@default>
Message-ID: <42d9b324-3b72-4a80-9132-9ac5ba01b269@default>

The fix looks good.

 

Regards,

Ajit

 

From: Ambarish Rapte 
Sent: Monday, September 19, 2016 4:15 PM
To: Sergey Bylokhov; Semyon Sadetsky; Ajit Ghaisas; awt-dev at openjdk.java.net
Subject: Review request for JDK-8166015: [PIT][TEST_BUG] stray character in java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java

 

Hi,

 

Please review this test bug fix for JDK9,

Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/

Bug: https://bugs.openjdk.java.net/browse/JDK-8166015

 

 

Issue:    An unwanted character causes compiler error.

Fix:         Removed the character & did few small corrections as guidelines.

 

 

Regards,

Ambarish

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/152e1da8/attachment.html>

From semyon.sadetsky at oracle.com  Mon Sep 19 13:10:05 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Mon, 19 Sep 2016 16:10:05 +0300
Subject: <AWT Dev> Review request for JDK-8166015: [PIT][TEST_BUG] stray
 character in
 java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java
In-Reply-To: <42d9b324-3b72-4a80-9132-9ac5ba01b269@default>
References: <a2151502-3e85-4dfb-8db3-b9d2693b9956@default>
	<42d9b324-3b72-4a80-9132-9ac5ba01b269@default>
Message-ID: <1c5de7ab-a646-73e7-583d-55db66f72399@oracle.com>

+1

--Semyon


On 9/19/2016 3:32 PM, Ajit Ghaisas wrote:
>
> The fix looks good.
>
> Regards,
>
> Ajit
>
> *From:* Ambarish Rapte
> *Sent:* Monday, September 19, 2016 4:15 PM
> *To:* Sergey Bylokhov; Semyon Sadetsky; Ajit Ghaisas; 
> awt-dev at openjdk.java.net
> *Subject:* Review request for JDK-8166015: [PIT][TEST_BUG] stray 
> character in 
> java/awt/Focus/ModalDialogActivationTest/ModalDialogActivationTest.java
>
> Hi,
>
> Please review this test bug fix for JDK9,
>
> Webrev: http://cr.openjdk.java.net/~arapte/8166015/webrev.00/ 
> <http://cr.openjdk.java.net/%7Earapte/8166015/webrev.00/>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8166015
>
> Issue:    An unwanted character causes compiler error.
>
> Fix:         Removed the character & did few small corrections as 
> guidelines.
>
> Regards,
>
> Ambarish
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/0c66f202/attachment.html>

From andy.ja.lee at gmail.com  Mon Sep 19 14:19:03 2016
From: andy.ja.lee at gmail.com (Andy Lee)
Date: Mon, 19 Sep 2016 10:19:03 -0400
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
Message-ID: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>

Not sure if this is the best place to ask, but I'm looking for good way to
prevent the JFrame/JDialog memory leaks caused by
https://bugs.openjdk.java.net/browse/JDK-8029147

The best solution I've found so far is to use reflection to dig in and null
out the 'target' fields on the LWComponentPeer and CPlatformWindow after
disposing.  This at least allows the JDialog/JFrame instance to be GC'd
(along with any heavier objects they may reference), but isn't optimal
since ultimately the LWComponentPeer and CPlatformWindow instances still
end up leaking.  Another problem with this approach is that we have
hundreds of uses of JFrames/JDialogs across our codebase and this
workaround would require each one of them to be modified to add this
special cleanup logic; I'd like to avoid that if at all possible~

Any suggestions?

~Andy Lee
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/bb623d1e/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 19 15:26:35 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Sep 2016 18:26:35 +0300
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
Message-ID: <4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>

Hi, Andy.
I suggest to check the latest jdk9 and jdk8. Do you able to reproduce 
this bug on jdk8u112?

On 19.09.16 17:19, Andy Lee wrote:
> Not sure if this is the best place to ask, but I'm looking for good way
> to prevent the JFrame/JDialog memory leaks caused
> by https://bugs.openjdk.java.net/browse/JDK-8029147
>
> The best solution I've found so far is to use reflection to dig in and
> null out the 'target' fields on the LWComponentPeer and CPlatformWindow
> after disposing.  This at least allows the JDialog/JFrame instance to be
> GC'd (along with any heavier objects they may reference), but isn't
> optimal since ultimately the LWComponentPeer and CPlatformWindow
> instances still end up leaking.  Another problem with this approach is
> that we have hundreds of uses of JFrames/JDialogs across our codebase
> and this workaround would require each one of them to be modified to add
> this special cleanup logic; I'd like to avoid that if at all possible~
>
> Any suggestions?
>
> ~Andy Lee


-- 
Best regards, Sergey.

From andy.ja.lee at gmail.com  Mon Sep 19 16:13:26 2016
From: andy.ja.lee at gmail.com (Andy Lee)
Date: Mon, 19 Sep 2016 12:13:26 -0400
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
Message-ID: <CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>

Yes, I just tried my test case on JDK 8u112 and I can still reproduce the
JFrame leak.

On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov <
Sergey.Bylokhov at oracle.com> wrote:

> Hi, Andy.
> I suggest to check the latest jdk9 and jdk8. Do you able to reproduce this
> bug on jdk8u112?
>
>
> On 19.09.16 17:19, Andy Lee wrote:
>
>> Not sure if this is the best place to ask, but I'm looking for good way
>> to prevent the JFrame/JDialog memory leaks caused
>> by https://bugs.openjdk.java.net/browse/JDK-8029147
>>
>> The best solution I've found so far is to use reflection to dig in and
>> null out the 'target' fields on the LWComponentPeer and CPlatformWindow
>> after disposing.  This at least allows the JDialog/JFrame instance to be
>> GC'd (along with any heavier objects they may reference), but isn't
>> optimal since ultimately the LWComponentPeer and CPlatformWindow
>> instances still end up leaking.  Another problem with this approach is
>> that we have hundreds of uses of JFrames/JDialogs across our codebase
>> and this workaround would require each one of them to be modified to add
>> this special cleanup logic; I'd like to avoid that if at all possible~
>>
>> Any suggestions?
>>
>> ~Andy Lee
>>
>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/afcbfa85/attachment-0001.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 19 18:51:12 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Sep 2016 21:51:12 +0300
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
Message-ID: <a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>

On 19.09.16 19:13, Andy Lee wrote:
> Yes, I just tried my test case on JDK 8u112 and I can still reproduce
> the JFrame leak.

And what about the latest jdk9?
https://jdk9.java.net/download

>
> On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     Hi, Andy.
>     I suggest to check the latest jdk9 and jdk8. Do you able to
>     reproduce this bug on jdk8u112?
>
>
>     On 19.09.16 17:19, Andy Lee wrote:
>
>         Not sure if this is the best place to ask, but I'm looking for
>         good way
>         to prevent the JFrame/JDialog memory leaks caused
>         by https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>
>         The best solution I've found so far is to use reflection to dig
>         in and
>         null out the 'target' fields on the LWComponentPeer and
>         CPlatformWindow
>         after disposing.  This at least allows the JDialog/JFrame
>         instance to be
>         GC'd (along with any heavier objects they may reference), but isn't
>         optimal since ultimately the LWComponentPeer and CPlatformWindow
>         instances still end up leaking.  Another problem with this
>         approach is
>         that we have hundreds of uses of JFrames/JDialogs across our
>         codebase
>         and this workaround would require each one of them to be
>         modified to add
>         this special cleanup logic; I'd like to avoid that if at all
>         possible~
>
>         Any suggestions?
>
>         ~Andy Lee
>
>
>
>     --
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 19 19:51:04 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Sep 2016 22:51:04 +0300
Subject: <AWT Dev> [8u/9] Review request 8156116 : [macosx] two JNI
 locals to delete in AWTWindow.m, CGraphicsEnv.m
In-Reply-To: <04FE1AEA-3BE1-4E16-9869-3A7C8AC2A74C@jetbrains.com>
References: <3A997BCF-4CCA-4DFB-8457-833F864088F9@jetbrains.com>
	<c9d0256c-244d-b7f4-92c8-2086abbe1dcb@oracle.com>
	<573B3A6E.5040103@jetbrains.com> <573C902A.2070200@oracle.com>
	<04FE1AEA-3BE1-4E16-9869-3A7C8AC2A74C@jetbrains.com>
Message-ID: <551a99be-a613-31cf-cbc2-8a7352fd2287@oracle.com>

Hi, Anton.
Should we backport it to jdk8u?

On 20.05.16 12:12, Anton Tarasov wrote:
> Thank you!
>
> Anton.
>
>> On 18 May 2016, at 18:54, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
>>
>> Looks fine to me too.
>>
>> Thanks,
>>
>> Alexander.
>>
>> On 05/17/2016 06:36 PM, Anton Tarasov wrote:
>>> Would anyone else please review the fix?
>>>
>>> Thanks
>>> Anton.
>>>
>>> On 5/5/2016 12:45 PM, Sergey Bylokhov wrote:
>>>> Looks fine.
>>>>
>>>> On 05.05.16 10:50, Anton Tarasov wrote:
>>>>> Hello,
>>>>>
>>>>> Please, review a simple fix:
>>>>>
>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8156116/jdk9/webrev.0
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156116
>>>>>
>>>>> Thanks,
>>>>> Anton.
>>>>
>>>>
>>>
>>
>


-- 
Best regards, Sergey.

From andy.ja.lee at gmail.com  Mon Sep 19 20:02:26 2016
From: andy.ja.lee at gmail.com (Andy Lee)
Date: Mon, 19 Sep 2016 16:02:26 -0400
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
	<a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
Message-ID: <CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>

In JDK 9 the problem seems to be partially fixed; only the most recently
closed JFrame leaks (ie, a temporary leak).  I was unable to get Visual VM
to connect to the Java 9 process so I'm not exactly sure what was
preventing the last JFrame from being GC'd.

The Java 9 behavior would be sufficient to solve most of our major issues,
but it will be quite some time before it becomes feasible to move our
application to Java 9 so it doesn't really help us.

On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> wrote:

> On 19.09.16 19:13, Andy Lee wrote:
>
>> Yes, I just tried my test case on JDK 8u112 and I can still reproduce
>> the JFrame leak.
>>
>
> And what about the latest jdk9?
> https://jdk9.java.net/download
>
>
>> On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>     Hi, Andy.
>>     I suggest to check the latest jdk9 and jdk8. Do you able to
>>     reproduce this bug on jdk8u112?
>>
>>
>>     On 19.09.16 17:19, Andy Lee wrote:
>>
>>         Not sure if this is the best place to ask, but I'm looking for
>>         good way
>>         to prevent the JFrame/JDialog memory leaks caused
>>         by https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>>
>>         The best solution I've found so far is to use reflection to dig
>>         in and
>>         null out the 'target' fields on the LWComponentPeer and
>>         CPlatformWindow
>>         after disposing.  This at least allows the JDialog/JFrame
>>         instance to be
>>         GC'd (along with any heavier objects they may reference), but
>> isn't
>>         optimal since ultimately the LWComponentPeer and CPlatformWindow
>>         instances still end up leaking.  Another problem with this
>>         approach is
>>         that we have hundreds of uses of JFrames/JDialogs across our
>>         codebase
>>         and this workaround would require each one of them to be
>>         modified to add
>>         this special cleanup logic; I'd like to avoid that if at all
>>         possible~
>>
>>         Any suggestions?
>>
>>         ~Andy Lee
>>
>>
>>
>>     --
>>     Best regards, Sergey.
>>
>>
>>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160919/9b38034d/attachment.html>

From Sergey.Bylokhov at oracle.com  Mon Sep 19 20:08:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 19 Sep 2016 23:08:13 +0300
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
	<a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
	<CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>
Message-ID: <f2444e01-d5e9-9cbb-5113-87ec3282d823@oracle.com>

On 19.09.16 23:02, Andy Lee wrote:
> In JDK 9 the problem seems to be partially fixed; only the most recently
> closed JFrame leaks (ie, a temporary leak).  I was unable to get Visual
> VM to connect to the Java 9 process so I'm not exactly sure what was
> preventing the last JFrame from being GC'd.

Can you place the code which uses JFrame somewhere? It seems that some 
of the related bugs were not backported, like:
https://bugs.openjdk.java.net/browse/JDK-8156116

I will check which one.

>
> The Java 9 behavior would be sufficient to solve most of our major
> issues, but it will be quite some time before it becomes feasible to
> move our application to Java 9 so it doesn't really help us.
>
> On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     On 19.09.16 19:13, Andy Lee wrote:
>
>         Yes, I just tried my test case on JDK 8u112 and I can still
>         reproduce
>         the JFrame leak.
>
>
>     And what about the latest jdk9?
>     https://jdk9.java.net/download
>
>
>         On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>         <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>         <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>
>             Hi, Andy.
>             I suggest to check the latest jdk9 and jdk8. Do you able to
>             reproduce this bug on jdk8u112?
>
>
>             On 19.09.16 17:19, Andy Lee wrote:
>
>                 Not sure if this is the best place to ask, but I'm
>         looking for
>                 good way
>                 to prevent the JFrame/JDialog memory leaks caused
>                 by https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>
>
>                 The best solution I've found so far is to use reflection
>         to dig
>                 in and
>                 null out the 'target' fields on the LWComponentPeer and
>                 CPlatformWindow
>                 after disposing.  This at least allows the JDialog/JFrame
>                 instance to be
>                 GC'd (along with any heavier objects they may
>         reference), but isn't
>                 optimal since ultimately the LWComponentPeer and
>         CPlatformWindow
>                 instances still end up leaking.  Another problem with this
>                 approach is
>                 that we have hundreds of uses of JFrames/JDialogs across our
>                 codebase
>                 and this workaround would require each one of them to be
>                 modified to add
>                 this special cleanup logic; I'd like to avoid that if at all
>                 possible~
>
>                 Any suggestions?
>
>                 ~Andy Lee
>
>
>
>             --
>             Best regards, Sergey.
>
>
>
>
>     --
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Mon Sep 19 23:12:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Sep 2016 02:12:34 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
In-Reply-To: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
Message-ID: <571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>

Hi, Manajit.
It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance" 
returns the new object per invocation, so it is not really 
sharedInstance. I am not sure I understand what is wrong in the current 
code, from the my point of view this is a correct singleton. It it true 
that the problem is in access to broken "instance" and not to 
"javaToMacKeyMap" inside the "instance"? If not then "javaToMacKeyMap" 
should be changed to "self.javaToMacKeyMap".
Do you have a test case to reproduce the bug?

On 19.09.16 15:26, Manajit Halder wrote:
> Hi All,
>
> Kindly review the fix for JDK9.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8165555
>
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>
> Issue:
> [macosx] VM crashes on second attempt to execute JCK interactive tests
> that use Robot (single JVM, agent)
>
> Cause:
> While executing the JCK test for the second time the robot was getting
> initialised once again and old instance of CRobotKeyCodeMapping was not
> available.
> Crash was observed while trying to access invalid instance of
> CRobotKeyCodeMapping.
>
> Fix:
> A new instance of CRobotKeyCodeMapping is created when robot is initialised.
>
> Regards,
> Manajit


-- 
Best regards, Sergey.

From anton.tarasov at jetbrains.com  Tue Sep 20 07:40:45 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 20 Sep 2016 10:40:45 +0300
Subject: <AWT Dev> [8u/9] Review request 8156116 : [macosx] two JNI
	locals to delete in AWTWindow.m, CGraphicsEnv.m
In-Reply-To: <551a99be-a613-31cf-cbc2-8a7352fd2287@oracle.com>
References: <3A997BCF-4CCA-4DFB-8457-833F864088F9@jetbrains.com>
	<c9d0256c-244d-b7f4-92c8-2086abbe1dcb@oracle.com>
	<573B3A6E.5040103@jetbrains.com> <573C902A.2070200@oracle.com>
	<04FE1AEA-3BE1-4E16-9869-3A7C8AC2A74C@jetbrains.com>
	<551a99be-a613-31cf-cbc2-8a7352fd2287@oracle.com>
Message-ID: <BDF6EC47-367D-43AA-A5B3-557830BA4BDC@jetbrains.com>

Hi Sergey,

Sure, I?ll send a request.

Anton.

> On 19 Sep 2016, at 22:51, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Anton.
> Should we backport it to jdk8u?
> 
> On 20.05.16 12:12, Anton Tarasov wrote:
>> Thank you!
>> 
>> Anton.
>> 
>>> On 18 May 2016, at 18:54, Alexander Zvegintsev <alexander.zvegintsev at oracle.com> wrote:
>>> 
>>> Looks fine to me too.
>>> 
>>> Thanks,
>>> 
>>> Alexander.
>>> 
>>> On 05/17/2016 06:36 PM, Anton Tarasov wrote:
>>>> Would anyone else please review the fix?
>>>> 
>>>> Thanks
>>>> Anton.
>>>> 
>>>> On 5/5/2016 12:45 PM, Sergey Bylokhov wrote:
>>>>> Looks fine.
>>>>> 
>>>>> On 05.05.16 10:50, Anton Tarasov wrote:
>>>>>> Hello,
>>>>>> 
>>>>>> Please, review a simple fix:
>>>>>> 
>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8156116/jdk9/webrev.0
>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8156116
>>>>>> 
>>>>>> Thanks,
>>>>>> Anton.
>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> -- 
> Best regards, Sergey.


From andy.ja.lee at gmail.com  Tue Sep 20 12:43:51 2016
From: andy.ja.lee at gmail.com (Andy Lee)
Date: Tue, 20 Sep 2016 08:43:51 -0400
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <f2444e01-d5e9-9cbb-5113-87ec3282d823@oracle.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
	<a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
	<CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>
	<f2444e01-d5e9-9cbb-5113-87ec3282d823@oracle.com>
Message-ID: <CAHokn3pgKmnDGt2w5EHFPxk1v=GBEZcN=xA7s+psUceHWqBQRA@mail.gmail.com>

Here is my test code that demonstrates the leak:
http://bonuslord.github.io/misc/FrameLeakDemo.java

In JDK 8 the output indicates 3 frames remaining even after closing all of
the JFrames.
In JDK 9 the output usually reports 1 frame remaining after closing all of
the frames, although sometimes all 3 JFrames get properly GC'd and the
output reports 0.

On Mon, Sep 19, 2016 at 4:08 PM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com
> wrote:

> On 19.09.16 23:02, Andy Lee wrote:
>
>> In JDK 9 the problem seems to be partially fixed; only the most recently
>> closed JFrame leaks (ie, a temporary leak).  I was unable to get Visual
>> VM to connect to the Java 9 process so I'm not exactly sure what was
>> preventing the last JFrame from being GC'd.
>>
>
> Can you place the code which uses JFrame somewhere? It seems that some of
> the related bugs were not backported, like:
> https://bugs.openjdk.java.net/browse/JDK-8156116
>
> I will check which one.
>
>
>> The Java 9 behavior would be sufficient to solve most of our major
>> issues, but it will be quite some time before it becomes feasible to
>> move our application to Java 9 so it doesn't really help us.
>>
>> On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>     On 19.09.16 19:13, Andy Lee wrote:
>>
>>         Yes, I just tried my test case on JDK 8u112 and I can still
>>         reproduce
>>         the JFrame leak.
>>
>>
>>     And what about the latest jdk9?
>>     https://jdk9.java.net/download
>>
>>
>>         On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>>         <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>         <mailto:Sergey.Bylokhov at oracle.com
>>
>>         <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>
>>             Hi, Andy.
>>             I suggest to check the latest jdk9 and jdk8. Do you able to
>>             reproduce this bug on jdk8u112?
>>
>>
>>             On 19.09.16 17:19, Andy Lee wrote:
>>
>>                 Not sure if this is the best place to ask, but I'm
>>         looking for
>>                 good way
>>                 to prevent the JFrame/JDialog memory leaks caused
>>                 by https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>
>>
>>                 The best solution I've found so far is to use reflection
>>         to dig
>>                 in and
>>                 null out the 'target' fields on the LWComponentPeer and
>>                 CPlatformWindow
>>                 after disposing.  This at least allows the JDialog/JFrame
>>                 instance to be
>>                 GC'd (along with any heavier objects they may
>>         reference), but isn't
>>                 optimal since ultimately the LWComponentPeer and
>>         CPlatformWindow
>>                 instances still end up leaking.  Another problem with this
>>                 approach is
>>                 that we have hundreds of uses of JFrames/JDialogs across
>> our
>>                 codebase
>>                 and this workaround would require each one of them to be
>>                 modified to add
>>                 this special cleanup logic; I'd like to avoid that if at
>> all
>>                 possible~
>>
>>                 Any suggestions?
>>
>>                 ~Andy Lee
>>
>>
>>
>>             --
>>             Best regards, Sergey.
>>
>>
>>
>>
>>     --
>>     Best regards, Sergey.
>>
>>
>>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160920/9252ab7f/attachment.html>

From semyon.sadetsky at oracle.com  Tue Sep 20 14:53:59 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 20 Sep 2016 17:53:59 +0300
Subject: <AWT Dev> [9] Review request for 8140311: SwingInterop crashes
 at window close
In-Reply-To: <cb841add-74ee-fce9-2c90-81b182992f6f@oracle.com>
References: <4229cc49-434f-d21f-e8c8-54ae95037784@oracle.com>
	<cb841add-74ee-fce9-2c90-81b182992f6f@oracle.com>
Message-ID: <a56d7262-e2fb-6447-2180-2fc8edf60ea0@oracle.com>

+1

--Semyon


On 9/14/2016 7:25 PM, Sergey Bylokhov wrote:
> Looks fine.
>
> On 13.09.16 22:14, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8140311/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8140311
>>
>> This issue is only reproducible when a window using CWarningWindow.
>> After window close we cancel HidingTask in CWarningWindow at java level,
>> however we do not cancel delayed execution of "perform" selector at
>> native level.
>> At this point cached JNIEnv value becomes invalid, which is leading to
>> crash.
>>
>
>


From semyon.sadetsky at oracle.com  Tue Sep 20 15:39:27 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Tue, 20 Sep 2016 18:39:27 +0300
Subject: <AWT Dev> [9] Review request for 8164536:
 enableSuddenTermination() - Not throws SecurityException if a security
 manager exists and it will not allow the caller to invoke System.exit
In-Reply-To: <a981c7e1-bc9d-2f36-6b88-81b8841393cb@oracle.com>
References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com>
	<137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com>
	<bce2662e-18f7-7a80-b045-9f584b523180@oracle.com>
	<1412d092-84aa-23b9-c5f8-bfcdcf04f007@oracle.com>
	<a981c7e1-bc9d-2f36-6b88-81b8841393cb@oracle.com>
Message-ID: <54a6e1b6-2f48-c719-7b7b-36703568da2f@oracle.com>

Looks good.

--Semyon


On 9/8/2016 6:02 PM, Alexander Zvegintsev wrote:
> Initially showWindowWithoutWarningBanner was added to deny the new API 
> functions invocation without permission check,
>
> but now it seems redundant, so I left only canProcessApplicationEvents 
> in the new webrev:
>
> cr.openjdk.java.net/~azvegint/jdk/9/8164536/02/
>
> -- 
> Thanks,
> Alexander.
>
> On 09/08/2016 04:53 PM, Sergey Bylokhov wrote:
>> On 31.08.16 3:27, Alexander Zvegintsev wrote:
>>> Hi Sergey,
>>>
>>> It could be, but actually RuntimePermission is used by eawt(sure we can
>>> change it too, but I don't see a point)
>>
>> It is still unclear to me why in most of the place we check two 
>> permissions? Can you please clarify what is the purpose of 
>> canProcessApplicationEvents and showWindowWithoutWarningBanner and 
>> why both are related for example to removeAppEventListener() method.
>>
>>>
>>> Please see the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/01/
>>>
>>> -- 
>>> Thanks,
>>> Alexander.
>>>
>>> On 30.08.2016 22:44, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> Probably the name of this permission can be added to 
>>>> AWTPermissions.java?
>>>> I am not sure why some of the methods require
>>>> "canProcessApplicationEvents" permission. For example
>>>> Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template
>>>> but it does not throw such exceptions and/or require similar 
>>>> permissions.
>>>>
>>>> On 30.08.16 21:58, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/
>>>>>
>>>>> for the issue
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8164536
>>>>>
>>>>> This fix add check for canProcessApplicationEvents runtime
>>>>> permission(currently used by eawt) for Desktop and Taskbar classes.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From Sergey.Bylokhov at oracle.com  Tue Sep 20 15:47:17 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Sep 2016 18:47:17 +0300
Subject: <AWT Dev> [9] Review request for 8164536:
 enableSuddenTermination() - Not throws SecurityException if a security
 manager exists and it will not allow the caller to invoke System.exit
In-Reply-To: <a981c7e1-bc9d-2f36-6b88-81b8841393cb@oracle.com>
References: <5c6d468d-495f-45d3-c29f-8087495906c8@oracle.com>
	<137d5dcf-4286-ffad-9c23-9c7a1bfa5213@oracle.com>
	<bce2662e-18f7-7a80-b045-9f584b523180@oracle.com>
	<1412d092-84aa-23b9-c5f8-bfcdcf04f007@oracle.com>
	<a981c7e1-bc9d-2f36-6b88-81b8841393cb@oracle.com>
Message-ID: <2d084a39-168e-2fca-b2f3-1bb106c53f31@oracle.com>

On 08.09.16 18:02, Alexander Zvegintsev wrote:
> Initially showWindowWithoutWarningBanner was added to deny the new API
> functions invocation without permission check,

Looks fine.

>
> but now it seems redundant, so I left only canProcessApplicationEvents
> in the new webrev:
>
> cr.openjdk.java.net/~azvegint/jdk/9/8164536/02/
>
> --
> Thanks,
> Alexander.
>
> On 09/08/2016 04:53 PM, Sergey Bylokhov wrote:
>> On 31.08.16 3:27, Alexander Zvegintsev wrote:
>>> Hi Sergey,
>>>
>>> It could be, but actually RuntimePermission is used by eawt(sure we can
>>> change it too, but I don't see a point)
>>
>> It is still unclear to me why in most of the place we check two
>> permissions? Can you please clarify what is the purpose of
>> canProcessApplicationEvents and showWindowWithoutWarningBanner and why
>> both are related for example to removeAppEventListener() method.
>>
>>>
>>> Please see the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/01/
>>>
>>> --
>>> Thanks,
>>> Alexander.
>>>
>>> On 30.08.2016 22:44, Sergey Bylokhov wrote:
>>>> Hi, Alexander.
>>>> Probably the name of this permission can be added to
>>>> AWTPermissions.java?
>>>> I am not sure why some of the methods require
>>>> "canProcessApplicationEvents" permission. For example
>>>> Taskbar.getTaskbar()? I guess Desktop.getDesktop() is used a template
>>>> but it does not throw such exceptions and/or require similar
>>>> permissions.
>>>>
>>>> On 30.08.16 21:58, Alexander Zvegintsev wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix
>>>>>
>>>>> http://cr.openjdk.java.net/~azvegint/jdk/9/8164536/00/
>>>>>
>>>>> for the issue
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8164536
>>>>>
>>>>> This fix add check for canProcessApplicationEvents runtime
>>>>> permission(currently used by eawt) for Desktop and Taskbar classes.
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Tue Sep 20 16:44:36 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 20 Sep 2016 19:44:36 +0300
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <CAHokn3pgKmnDGt2w5EHFPxk1v=GBEZcN=xA7s+psUceHWqBQRA@mail.gmail.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
	<a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
	<CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>
	<f2444e01-d5e9-9cbb-5113-87ec3282d823@oracle.com>
	<CAHokn3pgKmnDGt2w5EHFPxk1v=GBEZcN=xA7s+psUceHWqBQRA@mail.gmail.com>
Message-ID: <1cc4a85e-de90-8bde-0aed-54c6f9ab5eb6@oracle.com>

Hi, Andy.
You code lack of Frame.dispose(), so the frames are shown forever. You 
can update the test by these lines:
	frm.setVisible(true);
+        try {
+            Thread.sleep(1000);
+        } catch (InterruptedException e) {
+            e.printStackTrace();
+        }
+        frm.dispose();

And it will pass after some period of time on jdk8u112, and fails on 
jdk8u101. Can you please double check?

On 20.09.16 15:43, Andy Lee wrote:
> Here is my test code that demonstrates the
> leak: http://bonuslord.github.io/misc/FrameLeakDemo.java
>
> In JDK 8 the output indicates 3 frames remaining even after closing all
> of the JFrames.
> In JDK 9 the output usually reports 1 frame remaining after closing all
> of the frames, although sometimes all 3 JFrames get properly GC'd and
> the output reports 0.
>
> On Mon, Sep 19, 2016 at 4:08 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>
>     On 19.09.16 23:02, Andy Lee wrote:
>
>         In JDK 9 the problem seems to be partially fixed; only the most
>         recently
>         closed JFrame leaks (ie, a temporary leak).  I was unable to get
>         Visual
>         VM to connect to the Java 9 process so I'm not exactly sure what was
>         preventing the last JFrame from being GC'd.
>
>
>     Can you place the code which uses JFrame somewhere? It seems that
>     some of the related bugs were not backported, like:
>     https://bugs.openjdk.java.net/browse/JDK-8156116
>     <https://bugs.openjdk.java.net/browse/JDK-8156116>
>
>     I will check which one.
>
>
>         The Java 9 behavior would be sufficient to solve most of our major
>         issues, but it will be quite some time before it becomes feasible to
>         move our application to Java 9 so it doesn't really help us.
>
>         On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
>         <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>         <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>
>             On 19.09.16 19:13, Andy Lee wrote:
>
>                 Yes, I just tried my test case on JDK 8u112 and I can still
>                 reproduce
>                 the JFrame leak.
>
>
>             And what about the latest jdk9?
>             https://jdk9.java.net/download
>
>
>                 On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>                 <Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>
>         <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>
>                 <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>
>
>                 <mailto:Sergey.Bylokhov at oracle.com
>         <mailto:Sergey.Bylokhov at oracle.com>>>> wrote:
>
>                     Hi, Andy.
>                     I suggest to check the latest jdk9 and jdk8. Do you
>         able to
>                     reproduce this bug on jdk8u112?
>
>
>                     On 19.09.16 17:19, Andy Lee wrote:
>
>                         Not sure if this is the best place to ask, but I'm
>                 looking for
>                         good way
>                         to prevent the JFrame/JDialog memory leaks caused
>                         by
>         https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>
>
>         <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>>
>
>                         The best solution I've found so far is to use
>         reflection
>                 to dig
>                         in and
>                         null out the 'target' fields on the
>         LWComponentPeer and
>                         CPlatformWindow
>                         after disposing.  This at least allows the
>         JDialog/JFrame
>                         instance to be
>                         GC'd (along with any heavier objects they may
>                 reference), but isn't
>                         optimal since ultimately the LWComponentPeer and
>                 CPlatformWindow
>                         instances still end up leaking.  Another problem
>         with this
>                         approach is
>                         that we have hundreds of uses of
>         JFrames/JDialogs across our
>                         codebase
>                         and this workaround would require each one of
>         them to be
>                         modified to add
>                         this special cleanup logic; I'd like to avoid
>         that if at all
>                         possible~
>
>                         Any suggestions?
>
>                         ~Andy Lee
>
>
>
>                     --
>                     Best regards, Sergey.
>
>
>
>
>             --
>             Best regards, Sergey.
>
>
>
>
>     --
>     Best regards, Sergey.
>
>


-- 
Best regards, Sergey.

From andy.ja.lee at gmail.com  Tue Sep 20 17:44:22 2016
From: andy.ja.lee at gmail.com (Andy Lee)
Date: Tue, 20 Sep 2016 13:44:22 -0400
Subject: <AWT Dev> Best workaround for OSX Window leak? (JDK-8029147)
In-Reply-To: <1cc4a85e-de90-8bde-0aed-54c6f9ab5eb6@oracle.com>
References: <CAHokn3qKMJoR1ekpeeqqxFLWeZ=mw2Kg+Wbjj4UJYfgw7RnSjQ@mail.gmail.com>
	<4b23e3f9-6b0a-3188-86e1-3582d0749d07@oracle.com>
	<CAHokn3q5iBuSvMRhew-cArauLbBVX7EpdWnpGumHXGSM_+PWSQ@mail.gmail.com>
	<a2b13aac-5708-149c-b0fa-379a1cf3f8ab@oracle.com>
	<CAHokn3r+6nGtuaXeb5YqtPRCBsC3K_HsstPC1fYO_3iH+wV+Bg@mail.gmail.com>
	<f2444e01-d5e9-9cbb-5113-87ec3282d823@oracle.com>
	<CAHokn3pgKmnDGt2w5EHFPxk1v=GBEZcN=xA7s+psUceHWqBQRA@mail.gmail.com>
	<1cc4a85e-de90-8bde-0aed-54c6f9ab5eb6@oracle.com>
Message-ID: <CAHokn3qR72RVyjSdiYXwPhR4wkwjFg2zs1fnWx1i1MZjR0B6aA@mail.gmail.com>

Ah, now that is interesting...  I was actually closing the JFrames manually
by clicking the close button on the upper left corner of each window that
appeared (and since I set the default close operation to DISPOSE_ON_CLOSE,
this resulted in dispose() being called on each frame).

Indeed, using your modification to programmatically call dispose() allows
the JFrames to be properly GC'd in 8u112.  This is strange because I
confirmed that dispose was actually being called when I manually closed the
windows using the window decoration, so somehow the close button must be
doing something slightly different that is still causing the JFrames to
leak.

I modified my test case to do additional testing and discovered another odd
detail.  If you move the JFrame (by dragging its title bar with your mouse)
before disposing it via a manual call to dispose(), it also causes the
JFrame to leak.

Here's a link to my updated test case (basically just added buttons for
testing the different scenarios):
http://bonuslord.github.io/misc/FrameLeakDemo2.java

There seem to be 3 primary cases (I performed all testing on JDK 8u112):
1. Dispose all frames by clicking the 'Dispose Forever' button. Result: No
leak
2. Dispose all frames by using the window decoration. Result: All frames
leak
3. Move all of the frames by dragging on the title bar, then dispose using
the 'Dispose Forever' button. Result: All frames leak

I'm guessing case 2 and case 3 may have the same underlying cause since
both involve interacting with the native window title bar?

On Tue, Sep 20, 2016 at 12:44 PM, Sergey Bylokhov <
Sergey.Bylokhov at oracle.com> wrote:

> Hi, Andy.
> You code lack of Frame.dispose(), so the frames are shown forever. You can
> update the test by these lines:
>         frm.setVisible(true);
> +        try {
> +            Thread.sleep(1000);
> +        } catch (InterruptedException e) {
> +            e.printStackTrace();
> +        }
> +        frm.dispose();
>
> And it will pass after some period of time on jdk8u112, and fails on
> jdk8u101. Can you please double check?
>
> On 20.09.16 15:43, Andy Lee wrote:
>
>> Here is my test code that demonstrates the
>> leak: http://bonuslord.github.io/misc/FrameLeakDemo.java
>>
>> In JDK 8 the output indicates 3 frames remaining even after closing all
>> of the JFrames.
>> In JDK 9 the output usually reports 1 frame remaining after closing all
>> of the frames, although sometimes all 3 JFrames get properly GC'd and
>> the output reports 0.
>>
>> On Mon, Sep 19, 2016 at 4:08 PM, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>>     On 19.09.16 23:02, Andy Lee wrote:
>>
>>         In JDK 9 the problem seems to be partially fixed; only the most
>>         recently
>>         closed JFrame leaks (ie, a temporary leak).  I was unable to get
>>         Visual
>>         VM to connect to the Java 9 process so I'm not exactly sure what
>> was
>>         preventing the last JFrame from being GC'd.
>>
>>
>>     Can you place the code which uses JFrame somewhere? It seems that
>>     some of the related bugs were not backported, like:
>>     https://bugs.openjdk.java.net/browse/JDK-8156116
>>     <https://bugs.openjdk.java.net/browse/JDK-8156116>
>>
>>     I will check which one.
>>
>>
>>         The Java 9 behavior would be sufficient to solve most of our major
>>         issues, but it will be quite some time before it becomes feasible
>> to
>>         move our application to Java 9 so it doesn't really help us.
>>
>>         On Mon, Sep 19, 2016 at 2:51 PM, Sergey Bylokhov
>>         <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>
>>         <mailto:Sergey.Bylokhov at oracle.com
>>         <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>
>>             On 19.09.16 19:13, Andy Lee wrote:
>>
>>                 Yes, I just tried my test case on JDK 8u112 and I can
>> still
>>                 reproduce
>>                 the JFrame leak.
>>
>>
>>             And what about the latest jdk9?
>>             https://jdk9.java.net/download
>>
>>
>>                 On Mon, Sep 19, 2016 at 11:26 AM, Sergey Bylokhov
>>                 <Sergey.Bylokhov at oracle.com
>>         <mailto:Sergey.Bylokhov at oracle.com>
>>         <mailto:Sergey.Bylokhov at oracle.com
>>         <mailto:Sergey.Bylokhov at oracle.com>>
>>                 <mailto:Sergey.Bylokhov at oracle.com
>>         <mailto:Sergey.Bylokhov at oracle.com>
>>
>>                 <mailto:Sergey.Bylokhov at oracle.com
>>         <mailto:Sergey.Bylokhov at oracle.com>>>> wrote:
>>
>>                     Hi, Andy.
>>                     I suggest to check the latest jdk9 and jdk8. Do you
>>         able to
>>                     reproduce this bug on jdk8u112?
>>
>>
>>                     On 19.09.16 17:19, Andy Lee wrote:
>>
>>                         Not sure if this is the best place to ask, but I'm
>>                 looking for
>>                         good way
>>                         to prevent the JFrame/JDialog memory leaks caused
>>                         by
>>         https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>
>>
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>
>>                 <https://bugs.openjdk.java.net/browse/JDK-8029147
>>         <https://bugs.openjdk.java.net/browse/JDK-8029147>>>
>>
>>                         The best solution I've found so far is to use
>>         reflection
>>                 to dig
>>                         in and
>>                         null out the 'target' fields on the
>>         LWComponentPeer and
>>                         CPlatformWindow
>>                         after disposing.  This at least allows the
>>         JDialog/JFrame
>>                         instance to be
>>                         GC'd (along with any heavier objects they may
>>                 reference), but isn't
>>                         optimal since ultimately the LWComponentPeer and
>>                 CPlatformWindow
>>                         instances still end up leaking.  Another problem
>>         with this
>>                         approach is
>>                         that we have hundreds of uses of
>>         JFrames/JDialogs across our
>>                         codebase
>>                         and this workaround would require each one of
>>         them to be
>>                         modified to add
>>                         this special cleanup logic; I'd like to avoid
>>         that if at all
>>                         possible~
>>
>>                         Any suggestions?
>>
>>                         ~Andy Lee
>>
>>
>>
>>                     --
>>                     Best regards, Sergey.
>>
>>
>>
>>
>>             --
>>             Best regards, Sergey.
>>
>>
>>
>>
>>     --
>>     Best regards, Sergey.
>>
>>
>>
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160920/09180d0e/attachment.html>

From philip.race at oracle.com  Tue Sep 20 21:11:06 2016
From: philip.race at oracle.com (Philip Race)
Date: Tue, 20 Sep 2016 14:11:06 -0700
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <bbfcbe03-a710-488f-a691-23c2c7ba4738@default>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
	<01b1408e-76a8-4236-8286-45dd8e603b77@default>
	<57D6C6B7.6000104@oracle.com>
	<bbfcbe03-a710-488f-a691-23c2c7ba4738@default>
Message-ID: <57E1A5EA.4000905@oracle.com>

\                  HiDPI scaled image is also supported\n\
   94 \                  Unscaled image name i.e. image.ext should be passed\n\
   95 \                  to -splash option for all image types irrespective of\n\
   96 \                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
   97 \                  used for HiDPI images\n\


try this :-
HiDPI scaled images are automatically supported and used if available.
The unscaled image filename, e.g. image.ext, should always be passed as
the argument to the -splash option. The most appropriate scaled image
provided will be picked up automatically.
See the SplashScreen API documentation for more information.

-phil.

On 9/13/16, 12:03 AM, Rajeev Chamyal wrote:
> Hello Phil,
>
> Please review the updated webrev.
> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
>
> Updates:
> Updated documentation in src/java.desktop/share/classes/java/awt/SplashScreen.java
> Review comments from Kumar are also updated in launcher.properties.
>
> Regards,
> Rajeev Chamyal
>
> -----Original Message-----
> From: Kumar Srinivasan
> Sent: 12 September 2016 20:46
> To: Rajeev Chamyal
> Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
>
> -\                  HiDPI and Non-HiDPI.Scaled filename convention should be\n\
> +\                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
> +\                  used for HiDPI images\n\
>
> Space after .
>
> Approved, contingent on the above fix, I don't need to see another iteration.
>
> Thanks
> Kumar
>
>
> On 9/12/2016 5:25 AM, Rajeev Chamyal wrote:
>> Hello Kumar,
>>
>> Thanks for the review.
>> Please review the updated webrev.
>>
>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
>> Updates:
>> 1) Updated launcher properties.
>> 2) Corrected indentation in splashscreen_impl.c
>>
>> Regards,
>> Rajeev Chamyal
>>
>> -----Original Message-----
>> From: Kumar Srinivasan
>> Sent: 09 September 2016 21:32
>> To: Rajeev Chamyal
>> Cc: Philip Race; Alexander Scherbatiy; awt-dev at openjdk.java.net;
>> Sergey Bylokhov
>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 Unify
>> the HiDPI splash screen image naming convention
>>
>>
>> Hi Rajeev,
>> In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?
>>
>> btw: I think you have formatting/indent issues in this file:
>> libsplashscreen/splashscreen_impl.c
>>
>>
>> Thanks
>> Kumar
>>
>>
>>> Hello Kumar,Phil,
>>>
>>> Please review the update updated webrev.
>>>
>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
>>> Updates in files :
>>> src/java.base/share/classes/sun/launcher/resources/launcher.propertie
>>> s src/java.desktop/share/classes/java/awt/SplashScreen.java
>>>
>>> Regards,
>>> Rajeev Chamyal
>>>
>>> -----Original Message-----
>>> From: Kumar Srinivasan
>>> Sent: 02 September 2016 19:10
>>> To: Rajeev Chamyal
>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov;
>>> Philip Race
>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>> Unify the HiDPI splash screen image naming convention
>>>
>>>
>>> Hi,
>>>
>>>> Hello Kumar,
>>>>
>>>> I have further updated launcher.properties.
>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
>>>>
>>>> For documentation update I have already raise a bug.
>>>> https://bugs.openjdk.java.net/browse/JDK-8165009
>>> Ok.
>>>
>>> so what about ?
>>>
>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
>>> s ktop/share/classes/java/awt/SplashScreen.java
>>>
>>>
>>> This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
>>>
>>> Kumar
>>>
>>>> Regards,
>>>> Rajeev Chamyal
>>>>
>>>> -----Original Message-----
>>>> From: Kumar Srinivasan
>>>> Sent: 01 September 2016 19:17
>>>> To: Rajeev Chamyal
>>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov;
>>>> Philip Race
>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>> Unify the HiDPI splash screen image naming convention
>>>>
>>>>
>>>> Hello Rajeev,
>>>>
>>>> IMHO, this really belongs here:
>>>>
>>>> http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.d
>>>> e s ktop/share/classes/java/awt/SplashScreen.java
>>>>
>>>> and here:
>>>>
>>>> https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
>>>>
>>>> If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
>>>>
>>>>
>>>> Kumar
>>>>
>>>>
>>>>
>>>>> Hello Kumar,
>>>>>
>>>>> Can you please review the updated
>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.propert
>>>>> i e s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
>>>>>
>>>>> Regards,
>>>>> Rajeev Chamyal
>>>>>
>>>>> -----Original Message-----
>>>>> From: Philip Race
>>>>> Sent: 27 August 2016 03:10
>>>>> To: Rajeev Chamyal
>>>>> Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov
>>>>> Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
>>>>> Unify the HiDPI splash screen image naming convention
>>>>>
>>>>> Seems fine now.
>>>>> 1) Please do a CCC for this
>>>>> 2) Please file a doc. bug so docs team can update the HTML man page
>>>>> and also perhaps
>>>>> https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.h
>>>>> t
>>>>> m
>>>>> l
>>>>>
>>>>> -phil
>>>>>
>>>>> On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:
>>>>>> Hello Alexandr,
>>>>>>
>>>>>> Please review the updated webrev.
>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
>>>>>>
>>>>>> Regards,
>>>>>> Rajeev Chamyal
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Alexandr Scherbatiy
>>>>>> Sent: 25 August 2016 22:07
>>>>>> To: Rajeev Chamyal; Philip Race
>>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov
>>>>>> Subject: Re:<AWT Dev>   <Swing Dev>[9] Review Request JDK-8151787
>>>>>> Unify the HiDPI splash screen image naming convention
>>>>>>
>>>>>> On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:
>>>>>>> Hello Phil,
>>>>>>>
>>>>>>> Thanks for the review,
>>>>>>> Please review updated webrev.
>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
>>>>>>> Updated files:
>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prope
>>>>>>> r
>>>>>>> t
>>>>>>> i
>>>>>>> e s
>>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
>>>>>>> src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
>>>>>>> h
>>>>>>           The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
>>>>>>
>>>>>>          Thanks,
>>>>>>          Alexandr.
>>>>>>
>>>>>>> Regards,
>>>>>>> Rajeev Chamyal
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Phil Race
>>>>>>> Sent: 20 August 2016 01:47
>>>>>>> To: Rajeev Chamyal
>>>>>>> Cc: awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>>>> Scherbatiy
>>>>>>> Subject: Re:<AWT Dev>   <Swing Dev>[9] Review Request JDK-8151787
>>>>>>> Unify the HiDPI splash screen image naming convention
>>>>>>>
>>>>>>> I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>> On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:
>>>>>>>> Hello Phil,
>>>>>>>>
>>>>>>>> Please review the updated webrev.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
>>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
>>>>>>>>
>>>>>>>> Updated file
>>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prop
>>>>>>>> e
>>>>>>>> r
>>>>>>>> t
>>>>>>>> i
>>>>>>>> e
>>>>>>>> s
>>>>>>>>
>>>>>>>> Added all other supported name extensions.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Rajeev Chamyal
>>>>>>>>
>>>>>>>> *From:*Philip Race
>>>>>>>> *Sent:* 19 August 2016 04:48
>>>>>>>> *To:* Rajeev Chamyal
>>>>>>>> *Cc:* awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander
>>>>>>>> Scherbatiy
>>>>>>>> *Subject:* Re:<AWT Dev>   <Swing Dev>[9] Review Request
>>>>>>>> JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>>> convention
>>>>>>>>
>>>>>>>> Better, although it still does not document the supported set of
>>>>>>>> scale name extensions that we discussed/proposed off-line.
>>>>>>>>
>>>>>>>> -phil.
>>>>>>>>
>>>>>>>> On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
>>>>>>>>
>>>>>>>>            Hello Phil,
>>>>>>>>
>>>>>>>>            Thanks for the review.
>>>>>>>>
>>>>>>>>            Please review the updated webrev.
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
>>>>>>>>
>>>>>>>>            Updated file
>>>>>>>>
>>>>>>>> src/java.base/share/classes/sun/launcher/resources/launcher.prop
>>>>>>>> e
>>>>>>>> r
>>>>>>>> t
>>>>>>>> i
>>>>>>>> e
>>>>>>>> s
>>>>>>>>
>>>>>>>>            Regards,
>>>>>>>>
>>>>>>>>            Rajeev Chamyal
>>>>>>>>
>>>>>>>>            *From:*Phil Race
>>>>>>>>            *Sent:* 16 August 2016 22:28
>>>>>>>>            *To:* Alexandr Scherbatiy
>>>>>>>>            *Cc:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>>            <mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
>>>>>>>>            *Subject:* Re:<AWT Dev>   <Swing Dev>[9] Review Request JDK-8151787
>>>>>>>>            Unify the HiDPI splash screen image naming convention
>>>>>>>>
>>>>>>>>            On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>                The fix looks good to me.
>>>>>>>>
>>>>>>>>                It would be better if a native speaker look at the
>>>>>>>>                documentation change in the launcher.properties file.
>>>>>>>>
>>>>>>>>
>>>>>>>>            That documentation seems to cover only *some* of the extensions we
>>>>>>>>            discussed.
>>>>>>>>            It ought to cite all of them if it does so at all. How else are
>>>>>>>>            people supposed
>>>>>>>>            to know what they can use ? Where else are you documenting it?
>>>>>>>>            Perhaps the launcher "man" page should be updated too
>>>>>>>>            find . -name java.1
>>>>>>>>            ./src/linux/doc/man/java.1
>>>>>>>>            ./src/linux/doc/man/ja/java.1
>>>>>>>>            ./src/bsd/doc/man/java.1
>>>>>>>>            ./src/bsd/doc/man/ja/java.1
>>>>>>>>            ./src/solaris/doc/sun/man/man1/java.1
>>>>>>>>            ./src/solaris/doc/sun/man/man1/ja/java.1
>>>>>>>>
>>>>>>>>            .. although I think there is also some HTML version maintained by
>>>>>>>>            the pubs/docs team
>>>>>>>>            that is not in OpenJDK - the above does not include Windows or Mac.
>>>>>>>>            I don't know offhand what is recommended these days. We'll have to
>>>>>>>>            find someone
>>>>>>>>            who does more with the launcher to help point to where to do the
>>>>>>>>            documentation.
>>>>>>>>
>>>>>>>>            And the doc does not really explain what is going on here. Reading
>>>>>>>>            that I might
>>>>>>>>            think I am supposed to pass -splash:image at 2x.ext if I want a
>>>>>>>>            hi-dpi image
>>>>>>>>            and that is not the idea at all, is it ?
>>>>>>>>            The idea is you would still specify -splash:image.ext and the
>>>>>>>>            *implementation*
>>>>>>>>            will look for the most appropriate scaled image for the current
>>>>>>>>            desktop.
>>>>>>>>
>>>>>>>>            I think we should also have a CCC cover this (somehow).
>>>>>>>>
>>>>>>>>            -phil.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                Thanks,
>>>>>>>>                Alexandr.
>>>>>>>>
>>>>>>>>                On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
>>>>>>>>
>>>>>>>>                    Hello Alexandr,
>>>>>>>>
>>>>>>>>                    Please review the updated webrev.
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
>>>>>>>>
>>>>>>>>                    Updates :
>>>>>>>>
>>>>>>>>                    1)Updated the consition as suggested  if(*scaleFactor -
>>>>>>>>                    (int)*scaleFactor<   0.000001)
>>>>>>>>
>>>>>>>>                    2)Includes the changes of
>>>>>>>>
>>>>>>>> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>>
>>>>>>>>                    3)+        //map the splash co-ordinates as per system scale
>>>>>>>>                    +        splash->x /= splash->scaleFactor;
>>>>>>>>                    +        splash->y /= splash->scaleFactor;
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                    This change is required only for windows and linux. As we
>>>>>>>>                    use absolute system resolution for centring the splash on
>>>>>>>>                    screen on these.
>>>>>>>>
>>>>>>>>                    i.e. if system resolution is 1920 X 1080(i.e. unscaled
>>>>>>>>                    resolution) on windows and linux we use this for centring
>>>>>>>>                    the splash on screen. For mac scaled resolution is used
>>>>>>>>                    directly.
>>>>>>>>
>>>>>>>>                    Regards,
>>>>>>>>
>>>>>>>>                    Rajeev Chamyal
>>>>>>>>
>>>>>>>>                    *From:*Alexander Scherbatiy
>>>>>>>>                    *Sent:* 11 August 2016 14:44
>>>>>>>>                    *To:* Rajeev Chamyal; awt-dev at openjdk.java.net
>>>>>>>>                    <mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
>>>>>>>>                    Bylokhov
>>>>>>>>                    *Subject:* Re:<AWT Dev>   <Swing Dev>[9] Review Request
>>>>>>>>                    JDK-8151787 Unify the HiDPI splash screen image naming
>>>>>>>>                    convention
>>>>>>>>
>>>>>>>>                    On 10/08/16 19:24, Alexandr Scherbatiy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                        On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
>>>>>>>>
>>>>>>>>                            Hello All,
>>>>>>>>
>>>>>>>>                            Please review the following webrev.
>>>>>>>>
>>>>>>>>                            Bug:
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8151787
>>>>>>>>
>>>>>>>>                            Webrev:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
>>>>>>>>
>>>>>>>> <http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
>>>>>>>>
>>>>>>>>
>>>>>>>>                            Issue: Currently different naming conventions are
>>>>>>>>                            used for Hidpi image on different platforms.
>>>>>>>>
>>>>>>>>                            With this change the names will be unified across
>>>>>>>>                            all platforms.
>>>>>>>>
>>>>>>>>                            For a unscaled image image.ext following naming
>>>>>>>>                            convention will be followed.
>>>>>>>>
>>>>>>>>                            Unscaled name: image.ext
>>>>>>>>
>>>>>>>>                            Supported Scaled Names:
>>>>>>>>
>>>>>>>>                            If screen scale is integer number e.g. 2:
>>>>>>>>                            image at 2x.ext<mailto:image at 2x.ext>
>>>>>>>>
>>>>>>>>                            If screen scale is float value like 1.25:
>>>>>>>>
>>>>>>>> image at 125pct.ext<mailto:image at 125pct.ext>
>>>>>>>>
>>>>>>>>
>>>>>>>>                        The fix should be reviewed on the awt-dev alias.
>>>>>>>>
>>>>>>>>                        + if(*scaleFactor - (int)*scaleFactor<
>>>>>>>> 0.000001)
>>>>>>>>
>>>>>>>>                        Should there be so high precision there? Could only
>>>>>>>>                        percent values be compared like
>>>>>>>>                         if ((*scaleFactor *100) !=
>>>>>>>> ((int)(*scaleFactor))
>>>>>>>> *
>>>>>>>> 100)
>>>>>>>>
>>>>>>>>
>>>>>>>>                        +        //map the splash co-ordinates as per system scale
>>>>>>>>                        +        splash->x /= splash->scaleFactor;
>>>>>>>>                        +        splash->y /= splash->scaleFactor;
>>>>>>>>
>>>>>>>>                        It looks like the splash coordinates and sizes are
>>>>>>>>                        rescaled in different places. Is it possible to do
>>>>>>>>                        that in the same place? May be in
>>>>>>>>                        java_awt_SplashScreen.c file getBounds() function?
>>>>>>>>
>>>>>>>>
>>>>>>>>                    src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
>>>>>>>>                           *scaleFactor = getNativeScaleFactor();
>>>>>>>>
>>>>>>>>                    Could you also include the change which requires to add
>>>>>>>>                    some default output screen name to the
>>>>>>>>                    getNativeScaleFactor() function on Linux. There is the
>>>>>>>>                    discussion about that:
>>>>>>>>
>>>>>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
>>>>>>>> h
>>>>>>>> t
>>>>>>>> m
>>>>>>>> l
>>>>>>>>
>>>>>>>>                    Thanks,
>>>>>>>>                    Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                        Thanks,
>>>>>>>>                        Alexandr.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>                            Regards,
>>>>>>>>
>>>>>>>>                            Rajeev Chamyal
>>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160920/a7b96276/attachment-0001.html>

From rajeev.chamyal at oracle.com  Wed Sep 21 09:29:40 2016
From: rajeev.chamyal at oracle.com (Rajeev Chamyal)
Date: Wed, 21 Sep 2016 02:29:40 -0700 (PDT)
Subject: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the
 HiDPI splash screen image naming convention
In-Reply-To: <57E1A5EA.4000905@oracle.com>
References: <fd604cb2-cd2a-4227-91db-87e7c0184d16@default>
	<653e05a2-0d4a-348a-28dd-060ea1102715@oracle.com>
	<5839ed19-bafe-1d10-5fe9-6644104f7f0b@oracle.com>
	<020c37cc-c9af-4790-a591-29b71b410533@default>
	<6b6cea3d-da5a-e0a9-9b49-106ef7aef647@oracle.com>
	<57B34616.5030203@oracle.com>
	<434c2e89-9fcb-4f24-9ae4-c8d3d91f486d@default>
	<57B64223.8090304@oracle.com>
	<420cab11-7fec-4e12-a053-79ff9a1e1cd8@default>
	<16f60a92-ee77-047f-4430-5be8fa5ff820@oracle.com>
	<e89f924d-b823-413d-91eb-1983849cfd55@default>
	<9fd32539-c22b-5c81-4032-92d9263857e5@oracle.com>
	<a9f03f07-c15d-4a61-9d23-1ce363735d74@default>
	<57C0B745.3040601@oracle.com>
	<464e5282-0317-49eb-b03f-d937dc97af58@default>
	<57C83167.6080108@oracle.com>
	<f8b2254e-8ca3-4f1a-8088-6a847bec2c44@default>
	<57C9812C.1080104@oracle.com>
	<a46028af-92fc-4032-8c74-70a951be2839@default>
	<57D2DCF3.8000107@oracle.com>
	<01b1408e-76a8-4236-8286-45dd8e603b77@default>
	<57D6C6B7.6000104@oracle.com>
	<bbfcbe03-a710-488f-a691-23c2c7ba4738@default>
	<57E1A5EA.4000905@oracle.com>
Message-ID: <3dcccb28-fedd-4e24-8f4d-4f66d4c15f80@default>

Hello Phil,

 

Please review the updated webrev.

http://cr.openjdk.java.net/~rchamyal/8151787/webrev.10/ 

 

Updates: Updated launcher.properties as suggested.

 

Regards,

Rajeev Chamyal

 

From: Philip Race 
Sent: 21 September 2016 02:41
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; awt-dev at openjdk.java.net; Sergey Bylokhov; Kumar Srinivasan
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention

 

\                  HiDPI scaled image is also supported\n\
  94 \                  Unscaled image name i.e. image.ext should be passed\n\
  95 \                  to -splash option for all image types irrespective of\n\
  96 \                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
  97 \                  used for HiDPI images\n\
 
 
try this :-
HiDPI scaled images are automatically supported and used if available.
The unscaled image filename, e.g. image.ext, should always be passed as
the argument to the -splash option. The most appropriate scaled image
provided will be picked up automatically.
See the SplashScreen API documentation for more information.

-phil.

On 9/13/16, 12:03 AM, Rajeev Chamyal wrote: 

Hello Phil,
 
Please review the updated webrev.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
 
Updates:
Updated documentation in src/java.desktop/share/classes/java/awt/SplashScreen.java 
Review comments from Kumar are also updated in launcher.properties.
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Kumar Srinivasan 
Sent: 12 September 2016 20:46
To: Rajeev Chamyal
Cc: Philip Race; Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify the HiDPI splash screen image naming convention
 
-\                  HiDPI and Non-HiDPI.Scaled filename convention should be\n\
+\                  HiDPI and Non-HiDPI. Scaled filename convention should be\n\
+\                  used for HiDPI images\n\
 
Space after .
 
Approved, contingent on the above fix, I don't need to see another iteration.
 
Thanks
Kumar
 
 
On 9/12/2016 5:25 AM, Rajeev Chamyal wrote:

Hello Kumar,
 
Thanks for the review.
Please review the updated webrev.
 
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.09/
Updates:
1) Updated launcher properties.
2) Corrected indentation in splashscreen_impl.c
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Kumar Srinivasan
Sent: 09 September 2016 21:32
To: Rajeev Chamyal
Cc: Philip Race; Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; 
Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 Unify 
the HiDPI splash screen image naming convention
 
 
Hi Rajeev,
In launcher.properties do you need an additional line to say, one must use the filename conventions to specify resolution ?
 
btw: I think you have formatting/indent issues in this file:
libsplashscreen/splashscreen_impl.c
 
 
Thanks
Kumar
 
 

Hello Kumar,Phil,
 
Please review the update updated webrev.
 
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.08/
Updates in files :
src/java.base/share/classes/sun/launcher/resources/launcher.propertie
s src/java.desktop/share/classes/java/awt/SplashScreen.java
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Kumar Srinivasan
Sent: 02 September 2016 19:10
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov; 
Philip Race
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
Unify the HiDPI splash screen image naming convention
 
 
Hi,
 

Hello Kumar,
 
I have further updated launcher.properties.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.07/
 
For documentation update I have already raise a bug.
https://bugs.openjdk.java.net/browse/JDK-8165009

Ok.
 
so what about ?
 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.de
s ktop/share/classes/java/awt/SplashScreen.java
 
 
This is the SplashScreen specification, is it not ? But there seems to be no effort to clarify this specification ?
 
Kumar
 

Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Kumar Srinivasan
Sent: 01 September 2016 19:17
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov; 
Philip Race
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
Unify the HiDPI splash screen image naming convention
 
 
Hello Rajeev,
 
IMHO, this really belongs here:
 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/1c28399f1b50/src/java.d
e s ktop/share/classes/java/awt/SplashScreen.java
 
and here:
 
https://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html
 
If you can reduce the words in the launcher, it would be good, also please make sure the lines do not exceed 80 chars ie. the output of java -help.
 
 
Kumar
 
 
 

Hello Kumar,
 
Can you please review the updated
src/java.base/share/classes/sun/launcher/resources/launcher.propert
i e s http://cr.openjdk.java.net/~rchamyal/8151787/webrev.06/
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Philip Race
Sent: 27 August 2016 03:10
To: Rajeev Chamyal
Cc: Alexander Scherbatiy; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re: <AWT Dev> <Swing Dev>[9] Review Request JDK-8151787 
Unify the HiDPI splash screen image naming convention
 
Seems fine now.
1) Please do a CCC for this
2) Please file a doc. bug so docs team can update the HTML man page 
and also perhaps 
https://docs.oracle.com/javase/tutorial/uiswing/misc/splashscreen.h
t
m
l
 
-phil
 
On 8/25/16, 11:49 PM, Rajeev Chamyal wrote:

Hello Alexandr,
 
Please review the updated webrev.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.05/
 
Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Alexandr Scherbatiy
Sent: 25 August 2016 22:07
To: Rajeev Chamyal; Philip Race
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov
Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
Unify the HiDPI splash screen image naming convention
 
On 8/22/2016 2:13 PM, Rajeev Chamyal wrote:

Hello Phil,
 
Thanks for the review,
Please review updated webrev.
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.04/
Updated files:
src/java.base/share/classes/sun/launcher/resources/launcher.prope
r
t
i
e s
src/java.desktop/macosx/native/libsplashscreen/splashscreen_sys.m
src/java.desktop/macosx/native/libsplashscreen/splashscreen_config.
h

         The findScaledImageName(...) method is only used in splashscreen_sys.m file. Is it possible to not declare it in splashscreen_config.h?
 
        Thanks,
        Alexandr.
 

Regards,
Rajeev Chamyal
 
-----Original Message-----
From: Phil Race
Sent: 20 August 2016 01:47
To: Rajeev Chamyal
Cc: HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
Scherbatiy
Subject: Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787 
Unify the HiDPI splash screen image naming convention
 
I recall that in order to be consistent we concluded that @200pct and @300pct needed to be supported in addition to the @2x and @3x syntax.
 
-phil.
 
On 8/19/2016 3:41 AM, Rajeev Chamyal wrote:

Hello Phil,
 
Please review the updated webrev.
 
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.03/
HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/"<http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.03/>
 
Updated file
src/java.base/share/classes/sun/launcher/resources/launcher.prop
e
r
t
i
e
s
 
Added all other supported name extensions.
 
Regards,
 
Rajeev Chamyal
 
*From:*Philip Race
*Sent:* 19 August 2016 04:48
*To:* Rajeev Chamyal
*Cc:* HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net; Sergey Bylokhov; Alexander 
Scherbatiy
*Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
JDK-8151787 Unify the HiDPI splash screen image naming 
convention
 
Better, although it still does not document the supported set of 
scale name extensions that we discussed/proposed off-line.
 
-phil.
 
On 8/18/16, 5:39 AM, Rajeev Chamyal wrote:
 
          Hello Phil,
 
          Thanks for the review.
 
          Please review the updated webrev.
 
          
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.02/
          
HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/"<http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.02/>
 
          Updated file
 
src/java.base/share/classes/sun/launcher/resources/launcher.prop
e
r
t
i
e
s
 
          Regards,
 
          Rajeev Chamyal
 
          *From:*Phil Race
          *Sent:* 16 August 2016 22:28
          *To:* Alexandr Scherbatiy
          *Cc:* Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
          HYPERLINK "mailto:awt-dev at openjdk.java.net"<mailto:awt-dev at openjdk.java.net>; Sergey Bylokhov
          *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request JDK-8151787
          Unify the HiDPI splash screen image naming convention
 
          On 08/16/2016 09:41 AM, Alexandr Scherbatiy wrote:
 
 
              The fix looks good to me.
 
              It would be better if a native speaker look at the
              documentation change in the launcher.properties file.
 
 
          That documentation seems to cover only *some* of the extensions we
          discussed.
          It ought to cite all of them if it does so at all. How else are
          people supposed
          to know what they can use ? Where else are you documenting it?
          Perhaps the launcher "man" page should be updated too
          find . -name java.1
          ./src/linux/doc/man/java.1
          ./src/linux/doc/man/ja/java.1
          ./src/bsd/doc/man/java.1
          ./src/bsd/doc/man/ja/java.1
          ./src/solaris/doc/sun/man/man1/java.1
          ./src/solaris/doc/sun/man/man1/ja/java.1
 
          .. although I think there is also some HTML version maintained by
          the pubs/docs team
          that is not in OpenJDK - the above does not include Windows or Mac.
          I don't know offhand what is recommended these days. We'll have to
          find someone
          who does more with the launcher to help point to where to do the
          documentation.
 
          And the doc does not really explain what is going on here. Reading
          that I might
          think I am supposed to pass -splash:image at 2x.ext if I want a
          hi-dpi image
          and that is not the idea at all, is it ?
          The idea is you would still specify -splash:image.ext and the
          *implementation*
          will look for the most appropriate scaled image for the current
          desktop.
 
          I think we should also have a CCC cover this (somehow).
 
          -phil.
 
 
 
 
              Thanks,
              Alexandr.
 
              On 8/16/2016 8:26 AM, Rajeev Chamyal wrote:
 
                  Hello Alexandr,
 
                  Please review the updated webrev.
 
                  
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.01/
 
HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/"<http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.01/>
 
                  Updates :
 
                  1)Updated the consition as suggested  if(*scaleFactor -
                  (int)*scaleFactor<  0.000001)
 
                  2)Includes the changes of
 
src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
 
                  3)+        //map the splash co-ordinates as per system scale
                  +        splash->x /= splash->scaleFactor;
                  +        splash->y /= splash->scaleFactor;
 
 
 
                  This change is required only for windows and linux. As we
                  use absolute system resolution for centring the splash on
                  screen on these.
 
                  i.e. if system resolution is 1920 X 1080(i.e. unscaled
                  resolution) on windows and linux we use this for centring
                  the splash on screen. For mac scaled resolution is used
                  directly.
 
                  Regards,
 
                  Rajeev Chamyal
 
                  *From:*Alexander Scherbatiy
                  *Sent:* 11 August 2016 14:44
                  *To:* Rajeev Chamyal; HYPERLINK "mailto:awt-dev at openjdk.java.net"awt-dev at openjdk.java.net
                  HYPERLINK "mailto:awt-dev at openjdk.java.net"<mailto:awt-dev at openjdk.java.net>; Philip Race; Sergey
                  Bylokhov
                  *Subject:* Re:<AWT Dev>  <Swing Dev>[9] Review Request
                  JDK-8151787 Unify the HiDPI splash screen image naming
                  convention
 
                  On 10/08/16 19:24, Alexandr Scherbatiy wrote:
 
 
 
                      On 8/9/2016 11:18 AM, Rajeev Chamyal wrote:
 
                          Hello All,
 
                          Please review the following webrev.
 
                          Bug:
https://bugs.openjdk.java.net/browse/JDK-8151787
 
                          Webrev:
 
http://cr.openjdk.java.net/~rchamyal/8151787/webrev.00/
 
HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/"<http://cr.openjdk.java.net/%7Erchamyal/8151787/webrev.00/>
 
 
                          Issue: Currently different naming conventions are
                          used for Hidpi image on different platforms.
 
                          With this change the names will be unified across
                          all platforms.
 
                          For a unscaled image image.ext following naming
                          convention will be followed.
 
                          Unscaled name: image.ext
 
                          Supported Scaled Names:
 
                          If screen scale is integer number e.g. 2:
                          HYPERLINK "mailto:image at 2x.ext"image at 2x.extHYPERLINK "mailto:image at 2x.ext"<mailto:image at 2x.ext>
 
                          If screen scale is float value like 1.25:
                          
HYPERLINK "mailto:image at 125pct.ext"image at 125pct.extHYPERLINK "mailto:image at 125pct.ext"<mailto:image at 125pct.ext>
 
 
                      The fix should be reviewed on the awt-dev alias.
 
                      + if(*scaleFactor - (int)*scaleFactor<
0.000001)
 
                      Should there be so high precision there? Could only
                      percent values be compared like
                       if ((*scaleFactor *100) !=
((int)(*scaleFactor))
*
100)
 
 
                      +        //map the splash co-ordinates as per system scale
                      +        splash->x /= splash->scaleFactor;
                      +        splash->y /= splash->scaleFactor;
 
                      It looks like the splash coordinates and sizes are
                      rescaled in different places. Is it possible to do
                      that in the same place? May be in
                      java_awt_SplashScreen.c file getBounds() function?
 
 
                  src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c
                         *scaleFactor = getNativeScaleFactor();
 
                  Could you also include the change which requires to add
                  some default output screen name to the
                  getNativeScaleFactor() function on Linux. There is the
                  discussion about that:
 
http://mail.openjdk.java.net/pipermail/awt-dev/2016-August/011766.
h
t
m
l
 
                  Thanks,
                  Alexandr.
 
 
 
 
                      Thanks,
                      Alexandr.
 
 
 
 
                          Regards,
 
                          Rajeev Chamyal
 

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160921/82a847fb/attachment-0001.html>

From Alan.Burlison at oracle.com  Wed Sep 21 09:47:44 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Wed, 21 Sep 2016 10:47:44 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
Message-ID: <a39961b2-16b0-95df-11af-6e2662709442@oracle.com>

On 14/09/2016 18:42, Alan Burlison wrote:

> I'd appreciate any review comments.

Ping...

-- 
Alan Burlison
--

From manajit.halder at oracle.com  Wed Sep 21 13:01:52 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Wed, 21 Sep 2016 18:31:52 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
	VM crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
In-Reply-To: <571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
Message-ID: <E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>

Hi Sergey,

Thanks for the comment.

Access to "instance" is not broken. The problem is with the dictionary variable "javaToMacKeyMap" within the "instance" reference. 
The dictionary is not getting initialised for the second time when singleton method is called for the second time. The dictionary is 
getting initialised during the first time singleton method is called and hence crash was observed. Tried adding self.javaToMacKeyMap
but doesn?t solve the problem. 

I propose two solutions to this problem:

Solution 1:
	Reinitialise the dictionary every-time the singleton method is called.
	Webrev: 
		http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/>

	Drawback: 
		dictionary is initialised multiple times (every time singleton method is called).

Solution 2: 
	Make the dictionary static.
	Drawback:
		Still dictionary need to be initialised multiple times.
		No singleton method, just two static methods, one method to initialise the dictionary and other to get the key form the dictionary.
	
	Webrev: 
		Not prepared. Will be prepared if second solution accepted.

Test case:
	There are no test cases. Problem can be reproduced by executing following JCK test:
java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive "api/java_awt/interactive/event/EventTests.html#EventTest0019 api/java_awt/interactive/event/EventTests.html#EventTest0013? 

Thanks,
Manajit

> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hi, Manajit.
> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance" returns the new object per invocation, so it is not really sharedInstance. I am not sure I understand what is wrong in the current code, from the my point of view this is a correct singleton. It it true that the problem is in access to broken "instance" and not to "javaToMacKeyMap" inside the "instance"? If not then "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
> Do you have a test case to reproduce the bug?
> 
> On 19.09.16 15:26, Manajit Halder wrote:
>> Hi All,
>> 
>> Kindly review the fix for JDK9.
>> 
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8165555
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>> 
>> Issue:
>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>> that use Robot (single JVM, agent)
>> 
>> Cause:
>> While executing the JCK test for the second time the robot was getting
>> initialised once again and old instance of CRobotKeyCodeMapping was not
>> available.
>> Crash was observed while trying to access invalid instance of
>> CRobotKeyCodeMapping.
>> 
>> Fix:
>> A new instance of CRobotKeyCodeMapping is created when robot is initialised.
>> 
>> Regards,
>> Manajit
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160921/af02a3c9/attachment.html>

From ajit.ghaisas at oracle.com  Wed Sep 21 18:04:30 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Wed, 21 Sep 2016 11:04:30 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8058950 : [TESTBUG] There is no F1 dialog
 when the case loading, so we can't restore it.
Message-ID: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>

Hi,

Bug : 
     https://bugs.openjdk.java.net/browse/JDK-8058950

Issue :
    Minimized test frame cannot be restored.

Fix :
   1. The test fix is quite simple - to introduce delay between frame.setVisible(true) and frame.setExtendedState(Frame.ICONIFIED).
   2. I have modified test - not to use Applet. This results in multiple changes when file diff is seen.

Webrev :
   http://cr.openjdk.java.net/~aghaisas/8058950/webrev.00/

Request you to review.

Regards,
Ajit

From Sergey.Bylokhov at oracle.com  Thu Sep 22 17:01:56 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 Sep 2016 20:01:56 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8041519: JVM crash
 on second DnD after modal dialog opened during Swing DnD operation
In-Reply-To: <55B7C0D3.1060602@oracle.com>
References: <55A92CE0.70307@oracle.com> <55AEB98F.2020204@oracle.com>
	<55B7C0D3.1060602@oracle.com>
Message-ID: <4918fa9c-35ea-cdca-c831-4de5dde45db0@oracle.com>

On 28.07.15 20:50, Semyon Sadetsky wrote:
> Hi Sergey,
>
> Not sure that I understood what you are proposing. Could you clarify or
> rephrase?

I mean that we can handle instability of the test by ignoring all 
possible exceptions or something like that, and fails only in case of crash.

>
> --Semyon
>
> On 7/22/2015 12:28 AM, Sergey Bylokhov wrote:
>> Hi, Semyon.
>> Is it possible to write a test which ignore all possible exceptions
>> and will fail only in case of crash?
>>
>> On 17.07.15 19:27, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041519
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
>>>
>>> This is regression from JDK-6342381. When a modal dialog blocks drop
>>> operation in progress state consequent mouse events clear the drop
>>> context variables (this clearing was introduced by JDK-6342381). The
>>> solution is to avoid clearing if drop operation is in progress.
>>> Test scenario for this case would be too hard and unstable. Since the
>>> fix is pretty simple I left it as noreg.
>>>
>>> --Semyon
>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Sep 22 17:17:16 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 22 Sep 2016 20:17:16 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8041519: JVM crash
 on second DnD after modal dialog opened during Swing DnD operation
In-Reply-To: <4918fa9c-35ea-cdca-c831-4de5dde45db0@oracle.com>
References: <55A92CE0.70307@oracle.com> <55AEB98F.2020204@oracle.com>
	<55B7C0D3.1060602@oracle.com>
	<4918fa9c-35ea-cdca-c831-4de5dde45db0@oracle.com>
Message-ID: <7c03a587-ea92-3c78-1bb7-d96326be8856@oracle.com>

On 9/22/2016 8:01 PM, Sergey Bylokhov wrote:
> On 28.07.15 20:50, Semyon Sadetsky wrote:
>> Hi Sergey,
>>
>> Not sure that I understood what you are proposing. Could you clarify or
>> rephrase?
>
> I mean that we can handle instability of the test by ignoring all 
> possible exceptions or something like that, and fails only in case of 
> crash.
Will a manual test make you happy?
>
>>
>> --Semyon
>>
>> On 7/22/2015 12:28 AM, Sergey Bylokhov wrote:
>>> Hi, Semyon.
>>> Is it possible to write a test which ignore all possible exceptions
>>> and will fail only in case of crash?
>>>
>>> On 17.07.15 19:27, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041519
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
>>>>
>>>> This is regression from JDK-6342381. When a modal dialog blocks drop
>>>> operation in progress state consequent mouse events clear the drop
>>>> context variables (this clearing was introduced by JDK-6342381). The
>>>> solution is to avoid clearing if drop operation is in progress.
>>>> Test scenario for this case would be too hard and unstable. Since the
>>>> fix is pretty simple I left it as noreg.
>>>>
>>>> --Semyon
>>>>
>>>>
>>>
>>>
>>
>
>


From Sergey.Bylokhov at oracle.com  Thu Sep 22 17:26:47 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 22 Sep 2016 20:26:47 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8041519: JVM crash
 on second DnD after modal dialog opened during Swing DnD operation
In-Reply-To: <7c03a587-ea92-3c78-1bb7-d96326be8856@oracle.com>
References: <55A92CE0.70307@oracle.com> <55AEB98F.2020204@oracle.com>
	<55B7C0D3.1060602@oracle.com>
	<4918fa9c-35ea-cdca-c831-4de5dde45db0@oracle.com>
	<7c03a587-ea92-3c78-1bb7-d96326be8856@oracle.com>
Message-ID: <ab19b2f2-cae3-4457-6901-890ed8458d78@oracle.com>

On 22.09.16 20:17, Semyon Sadetsky wrote:
> On 9/22/2016 8:01 PM, Sergey Bylokhov wrote:
>> On 28.07.15 20:50, Semyon Sadetsky wrote:
>>> Hi Sergey,
>>>
>>> Not sure that I understood what you are proposing. Could you clarify or
>>> rephrase?
>>
>> I mean that we can handle instability of the test by ignoring all
>> possible exceptions or something like that, and fails only in case of
>> crash.
> Will a manual test make you happy?

It will be good to automate it in some way, but if it is not possible 
when we can add a manual test.

>>> On 7/22/2015 12:28 AM, Sergey Bylokhov wrote:
>>>> Hi, Semyon.
>>>> Is it possible to write a test which ignore all possible exceptions
>>>> and will fail only in case of crash?
>>>>
>>>> On 17.07.15 19:27, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8041519
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8041519/webrev.00/
>>>>>
>>>>> This is regression from JDK-6342381. When a modal dialog blocks drop
>>>>> operation in progress state consequent mouse events clear the drop
>>>>> context variables (this clearing was introduced by JDK-6342381). The
>>>>> solution is to avoid clearing if drop operation is in progress.
>>>>> Test scenario for this case would be too hard and unstable. Since the
>>>>> fix is pretty simple I left it as noreg.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 13:15:16 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 16:15:16 +0300
Subject: <AWT Dev> [9] Review request for 8165619: Frame is not repainted if
 created in state=MAXIMIZED_BOTH on Unity
Message-ID: <2a6cfd77-3768-2969-87df-55a87ab614a1@oracle.com>

Hello,

Please review fix for JDK9:

bug: https://bugs.openjdk.java.net/browse/JDK-8165619

webrev: http://cr.openjdk.java.net/~ssadetsky/8165619/webrev.00/

If frame is created in maximized the window extent property notification 
is not send by WM. So, ConfigureNotify event is skipped and the target 
frame doesn't receive notification about size and its content is not 
repainted.  To handle this scenario the waiting for window extents is 
canceled for maximized window and the extents are specified when window 
state is changed back to normal.

--Semyon


From Sergey.Bylokhov at oracle.com  Fri Sep 23 13:51:13 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 16:51:13 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
Message-ID: <f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>

On 01.09.16 16:41, Semyon Sadetsky wrote:
>
>
> On 31.08.2016 21:18, Sergey Bylokhov wrote:
>> On 31.08.16 17:18, Semyon Sadetsky wrote:
>>> Toolkit.getDefaultToolkit().getScreenSize()
>>>
>>> was replaced by
>>>
>>> graphicsConfig.getBounds();
>>>
>>> that returns a particular screen area which is not the same as the joint
>>> screen area in case of Xinerama multi-monitor configuration.
>>
>> Can you please clarify what is the difference between two methods in
>> this bug? Toolkit.getScreenSize() is related to the main screen
>> only(defaul gc config), but gc.getBounds() is related to appropriate
>> screen(and take scale factor of those screen into account). In case of
>> xinerama we should have two GC which should have each own scales.
> It was explained above already: they return different things.
> Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds()
> returns particular screen bounds.

I do not get it. Toolkit.getScreenSize() should return the size of the 
primary screen which is default screen device in terms of 
GraphicsEnvironment.



-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 14:00:58 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 17:00:58 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
Message-ID: <1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>



On 23.09.2016 16:51, Sergey Bylokhov wrote:
> On 01.09.16 16:41, Semyon Sadetsky wrote:
>>
>>
>> On 31.08.2016 21:18, Sergey Bylokhov wrote:
>>> On 31.08.16 17:18, Semyon Sadetsky wrote:
>>>> Toolkit.getDefaultToolkit().getScreenSize()
>>>>
>>>> was replaced by
>>>>
>>>> graphicsConfig.getBounds();
>>>>
>>>> that returns a particular screen area which is not the same as the 
>>>> joint
>>>> screen area in case of Xinerama multi-monitor configuration.
>>>
>>> Can you please clarify what is the difference between two methods in
>>> this bug? Toolkit.getScreenSize() is related to the main screen
>>> only(defaul gc config), but gc.getBounds() is related to appropriate
>>> screen(and take scale factor of those screen into account). In case of
>>> xinerama we should have two GC which should have each own scales.
>> It was explained above already: they return different things.
>> Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds()
>> returns particular screen bounds.
>
> I do not get it. Toolkit.getScreenSize() should return the size of the 
> primary screen which is default screen device in terms of 
> GraphicsEnvironment.
No, it is a whole desktop size (joint virtual screen in case of 
multi-monitor). It has been working that way always.

From Sergey.Bylokhov at oracle.com  Fri Sep 23 14:31:56 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 17:31:56 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
Message-ID: <4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>

On 23.09.16 17:00, Semyon Sadetsky wrote:
>>>> On 31.08.16 17:18, Semyon Sadetsky wrote:
>>>>> Toolkit.getDefaultToolkit().getScreenSize()
>>>>>
>>>>> was replaced by
>>>>>
>>>>> graphicsConfig.getBounds();
>>>>>
>>>>> that returns a particular screen area which is not the same as the
>>>>> joint
>>>>> screen area in case of Xinerama multi-monitor configuration.
>>>>
>>>> Can you please clarify what is the difference between two methods in
>>>> this bug? Toolkit.getScreenSize() is related to the main screen
>>>> only(defaul gc config), but gc.getBounds() is related to appropriate
>>>> screen(and take scale factor of those screen into account). In case of
>>>> xinerama we should have two GC which should have each own scales.
>>> It was explained above already: they return different things.
>>> Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds()
>>> returns particular screen bounds.
>>
>> I do not get it. Toolkit.getScreenSize() should return the size of the
>> primary screen which is default screen device in terms of
>> GraphicsEnvironment.
> No, it is a whole desktop size (joint virtual screen in case of
> multi-monitor). It has been working that way always.

Then this is a bug.


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 14:35:26 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 17:35:26 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
Message-ID: <4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>



On 23.09.2016 17:31, Sergey Bylokhov wrote:
> On 23.09.16 17:00, Semyon Sadetsky wrote:
>>>>> On 31.08.16 17:18, Semyon Sadetsky wrote:
>>>>>> Toolkit.getDefaultToolkit().getScreenSize()
>>>>>>
>>>>>> was replaced by
>>>>>>
>>>>>> graphicsConfig.getBounds();
>>>>>>
>>>>>> that returns a particular screen area which is not the same as the
>>>>>> joint
>>>>>> screen area in case of Xinerama multi-monitor configuration.
>>>>>
>>>>> Can you please clarify what is the difference between two methods in
>>>>> this bug? Toolkit.getScreenSize() is related to the main screen
>>>>> only(defaul gc config), but gc.getBounds() is related to appropriate
>>>>> screen(and take scale factor of those screen into account). In 
>>>>> case of
>>>>> xinerama we should have two GC which should have each own scales.
>>>> It was explained above already: they return different things.
>>>> Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds()
>>>> returns particular screen bounds.
>>>
>>> I do not get it. Toolkit.getScreenSize() should return the size of the
>>> primary screen which is default screen device in terms of
>>> GraphicsEnvironment.
>> No, it is a whole desktop size (joint virtual screen in case of
>> multi-monitor). It has been working that way always.
>
> Then this is a bug.
Why?


From Sergey.Bylokhov at oracle.com  Fri Sep 23 14:49:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 17:49:41 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
Message-ID: <68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>

On 23.09.16 17:35, Semyon Sadetsky wrote:
>>>>>>> that returns a particular screen area which is not the same as the
>>>>>>> joint
>>>>>>> screen area in case of Xinerama multi-monitor configuration.
>>>>>>
>>>>>> Can you please clarify what is the difference between two methods in
>>>>>> this bug? Toolkit.getScreenSize() is related to the main screen
>>>>>> only(defaul gc config), but gc.getBounds() is related to appropriate
>>>>>> screen(and take scale factor of those screen into account). In
>>>>>> case of
>>>>>> xinerama we should have two GC which should have each own scales.
>>>>> It was explained above already: they return different things.
>>>>> Toolkit.getScreenSize() returns the whole desktop size, gc.getBounds()
>>>>> returns particular screen bounds.
>>>>
>>>> I do not get it. Toolkit.getScreenSize() should return the size of the
>>>> primary screen which is default screen device in terms of
>>>> GraphicsEnvironment.
>>> No, it is a whole desktop size (joint virtual screen in case of
>>> multi-monitor). It has been working that way always.
>>
>> Then this is a bug.
> Why?

Because it does not work as it should.


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 15:46:56 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 18:46:56 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
Message-ID: <98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>



On 23.09.2016 17:49, Sergey Bylokhov wrote:
> On 23.09.16 17:35, Semyon Sadetsky wrote:
>>>>>>>> that returns a particular screen area which is not the same as the
>>>>>>>> joint
>>>>>>>> screen area in case of Xinerama multi-monitor configuration.
>>>>>>>
>>>>>>> Can you please clarify what is the difference between two 
>>>>>>> methods in
>>>>>>> this bug? Toolkit.getScreenSize() is related to the main screen
>>>>>>> only(defaul gc config), but gc.getBounds() is related to 
>>>>>>> appropriate
>>>>>>> screen(and take scale factor of those screen into account). In
>>>>>>> case of
>>>>>>> xinerama we should have two GC which should have each own scales.
>>>>>> It was explained above already: they return different things.
>>>>>> Toolkit.getScreenSize() returns the whole desktop size, 
>>>>>> gc.getBounds()
>>>>>> returns particular screen bounds.
>>>>>
>>>>> I do not get it. Toolkit.getScreenSize() should return the size of 
>>>>> the
>>>>> primary screen which is default screen device in terms of
>>>>> GraphicsEnvironment.
>>>> No, it is a whole desktop size (joint virtual screen in case of
>>>> multi-monitor). It has been working that way always.
>>>
>>> Then this is a bug.
>> Why?
>
> Because it does not work as it should.
Interesting... How did you conclude that?
>


From Sergey.Bylokhov at oracle.com  Fri Sep 23 16:03:40 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 19:03:40 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
Message-ID: <c4437474-41a6-634b-447f-554af8c20656@oracle.com>

On 23.09.16 18:46, Semyon Sadetsky wrote:
>>>>>> I do not get it. Toolkit.getScreenSize() should return the size of
>>>>>> the
>>>>>> primary screen which is default screen device in terms of
>>>>>> GraphicsEnvironment.
>>>>> No, it is a whole desktop size (joint virtual screen in case of
>>>>> multi-monitor). It has been working that way always.
>>>>
>>>> Then this is a bug.
>>> Why?
>>
>> Because it does not work as it should.
> Interesting... How did you conclude that?

Because it should return the bounds of the primary screen, not "combined 
virtual screen". Also its spec should be updated to mention units 
instead of real pixels which differs in HiDPI.


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 23 16:08:56 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 19:08:56 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
In-Reply-To: <E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
	<E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
Message-ID: <d0ad2128-fae6-2f5d-d6c3-207b2abfdd7e@oracle.com>

On 21.09.16 16:01, Manajit Halder wrote:
> Access to "instance" is not broken. The problem is with the dictionary
> variable "javaToMacKeyMap" within the "instance" reference.
> The dictionary is not getting initialised for the second time when
> singleton method is called for the second time. The dictionary is
> getting initialised during the first time singleton method is called and
> hence crash was observed. Tried adding self.javaToMacKeyMap
> but doesn?t solve the problem.

If the "instance" is correct object then why the field inside is not 
initialized, probably we incorrectly release it somewhere?

>
> I propose two solutions to this problem:
>
> Solution 1:
> Reinitialise the dictionary every-time the singleton method is called.
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>
> Drawback:
> dictionary is initialised multiple times (every time singleton method is
> called).
>
> Solution 2:
> Make the dictionary static.
> Drawback:
> Still dictionary need to be initialised multiple times.
> No singleton method, just two static methods, one method to initialise
> the dictionary and other to get the key form the dictionary.
> Webrev:
> Not prepared. Will be prepared if second solution accepted.
>
> Test case:
> There are no test cases. Problem can be reproduced by
> executing following JCK test:
> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
> "api/java_awt/interactive/event/EventTests.html#EventTest0019
> api/java_awt/interactive/event/EventTests.html#EventTest0013?
>
> Thanks,
> Manajit
>
>> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
>> returns the new object per invocation, so it is not really
>> sharedInstance. I am not sure I understand what is wrong in the
>> current code, from the my point of view this is a correct singleton.
>> It it true that the problem is in access to broken "instance" and not
>> to "javaToMacKeyMap" inside the "instance"? If not then
>> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
>> Do you have a test case to reproduce the bug?
>>
>> On 19.09.16 15:26, Manajit Halder wrote:
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8165555
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>>
>>> Issue:
>>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>>> that use Robot (single JVM, agent)
>>>
>>> Cause:
>>> While executing the JCK test for the second time the robot was getting
>>> initialised once again and old instance of CRobotKeyCodeMapping was not
>>> available.
>>> Crash was observed while trying to access invalid instance of
>>> CRobotKeyCodeMapping.
>>>
>>> Fix:
>>> A new instance of CRobotKeyCodeMapping is created when robot is
>>> initialised.
>>>
>>> Regards,
>>> Manajit
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 16:22:42 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 19:22:42 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <c4437474-41a6-634b-447f-554af8c20656@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
Message-ID: <89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>

On 23.09.2016 19:03, Sergey Bylokhov wrote:

> On 23.09.16 18:46, Semyon Sadetsky wrote:
>>>>>>> I do not get it. Toolkit.getScreenSize() should return the size of
>>>>>>> the
>>>>>>> primary screen which is default screen device in terms of
>>>>>>> GraphicsEnvironment.
>>>>>> No, it is a whole desktop size (joint virtual screen in case of
>>>>>> multi-monitor). It has been working that way always.
>>>>>
>>>>> Then this is a bug.
>>>> Why?
>>>
>>> Because it does not work as it should.
>> Interesting... How did you conclude that?
>
> Because it should return the bounds of the primary screen, not 
> "combined virtual screen". Also its spec should be updated to mention 
> units instead of real pixels which differs in HiDPI.
Screen is a platform dependent term. In case Xinerama is on there is 
only one screen in multi-monitor configuration. In this case individual 
monitor parameters still can be get using special Xrandr library but for 
window manager there is only one screen (combined). Since java toolkit 
communicates to WM it should use WM's "language".


From Sergey.Bylokhov at oracle.com  Fri Sep 23 16:31:45 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 19:31:45 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
Message-ID: <7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>

On 23.09.16 19:22, Semyon Sadetsky wrote:
>> Because it should return the bounds of the primary screen, not
>> "combined virtual screen". Also its spec should be updated to mention
>> units instead of real pixels which differs in HiDPI.
> Screen is a platform dependent term. In case Xinerama is on there is
> only one screen in multi-monitor configuration. In this case individual
> monitor parameters still can be get using special Xrandr library but for
> window manager there is only one screen (combined). Since java toolkit
> communicates to WM it should use WM's "language".

Screen in our specification is a our own term. We have GraphicsDevice 
per screen. We have s special notion about "combined virtual screen" 
which "share the same coordinate system". Our methods and specification 
are not depends from the native WM implementation. In the current 
discussion toolkit should return the bounds of the primary screen which 
is default GraphicsDevice. So in the current fix the code related to 
popup menu should be updated. The new bug should be filed against toolkit.

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 23 16:54:33 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 19:54:33 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
In-Reply-To: <E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
	<E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
Message-ID: <53d96f6e-0809-13bb-099e-396c611bdf4b@oracle.com>

On 21.09.16 16:01, Manajit Halder wrote:
> Hi Sergey,
>
> Thanks for the comment.
>
> Access to "instance" is not broken. The problem is with the dictionary
> variable "javaToMacKeyMap" within the "instance" reference.
> The dictionary is not getting initialised for the second time when
> singleton method is called for the second time. The dictionary is
> getting initialised during the first time singleton method is called and
> hence crash was observed. Tried adding self.javaToMacKeyMap
> but doesn?t solve the problem.

I still suggest you to check "self.javaToMacKeyMap" at line 48 this 
should call generated setter which will retain the reference.

>
> I propose two solutions to this problem:
>
> Solution 1:
> Reinitialise the dictionary every-time the singleton method is called.
> Webrev:
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>
> Drawback:
> dictionary is initialised multiple times (every time singleton method is
> called).
>
> Solution 2:
> Make the dictionary static.
> Drawback:
> Still dictionary need to be initialised multiple times.
> No singleton method, just two static methods, one method to initialise
> the dictionary and other to get the key form the dictionary.
> Webrev:
> Not prepared. Will be prepared if second solution accepted.
>
> Test case:
> There are no test cases. Problem can be reproduced by
> executing following JCK test:
> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
> "api/java_awt/interactive/event/EventTests.html#EventTest0019
> api/java_awt/interactive/event/EventTests.html#EventTest0013?
>
> Thanks,
> Manajit
>
>> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> Hi, Manajit.
>> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
>> returns the new object per invocation, so it is not really
>> sharedInstance. I am not sure I understand what is wrong in the
>> current code, from the my point of view this is a correct singleton.
>> It it true that the problem is in access to broken "instance" and not
>> to "javaToMacKeyMap" inside the "instance"? If not then
>> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
>> Do you have a test case to reproduce the bug?
>>
>> On 19.09.16 15:26, Manajit Halder wrote:
>>> Hi All,
>>>
>>> Kindly review the fix for JDK9.
>>>
>>> Bug:
>>> https://bugs.openjdk.java.net/browse/JDK-8165555
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>>
>>> Issue:
>>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>>> that use Robot (single JVM, agent)
>>>
>>> Cause:
>>> While executing the JCK test for the second time the robot was getting
>>> initialised once again and old instance of CRobotKeyCodeMapping was not
>>> available.
>>> Crash was observed while trying to access invalid instance of
>>> CRobotKeyCodeMapping.
>>>
>>> Fix:
>>> A new instance of CRobotKeyCodeMapping is created when robot is
>>> initialised.
>>>
>>> Regards,
>>> Manajit
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 17:40:01 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 20:40:01 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
Message-ID: <813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>



On 23.09.2016 19:31, Sergey Bylokhov wrote:
> On 23.09.16 19:22, Semyon Sadetsky wrote:
>>> Because it should return the bounds of the primary screen, not
>>> "combined virtual screen". Also its spec should be updated to mention
>>> units instead of real pixels which differs in HiDPI.
>> Screen is a platform dependent term. In case Xinerama is on there is
>> only one screen in multi-monitor configuration. In this case individual
>> monitor parameters still can be get using special Xrandr library but for
>> window manager there is only one screen (combined). Since java toolkit
>> communicates to WM it should use WM's "language".
>
> Screen in our specification is a our own term. We have GraphicsDevice 
> per screen. We have s special notion about "combined virtual screen" 
> which "share the same coordinate system". Our methods and 
> specification are not depends from the native WM implementation. In 
> the current discussion toolkit should return the bounds of the primary 
> screen which is default GraphicsDevice. So in the current fix the code 
> related to popup menu should be updated. The new bug should be filed 
> against toolkit.
Sorry, i didn't get what do you think should be updated in the current 
fix? This is a regression fix. I just reverted part of the previous 
patch to fix the problem. And in all places I changed the whole desktop 
size should be used, not a primary monitor screen size. And 
Toolkit.getScreenSize() has been always returning the whole desktop.
If you think that Toolkit.getScreenSize() should be changed to return 
the monitor-1 size, I don't mind to file a separate bug. I'm sure it 
will require to revise a lot of usages of the method including those 
you've mentioned. Probably, it will cause compatibility issues and will 
not be approved then. So, how is that related to the current fix?


From Sergey.Bylokhov at oracle.com  Fri Sep 23 17:52:48 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 20:52:48 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
Message-ID: <19007d0e-6007-116f-0257-5db26a49450b@oracle.com>

On 23.09.16 20:40, Semyon Sadetsky wrote:
>> Screen in our specification is a our own term. We have GraphicsDevice
>> per screen. We have s special notion about "combined virtual screen"
>> which "share the same coordinate system". Our methods and
>> specification are not depends from the native WM implementation. In
>> the current discussion toolkit should return the bounds of the primary
>> screen which is default GraphicsDevice. So in the current fix the code
>> related to popup menu should be updated. The new bug should be filed
>> against toolkit.
> Sorry, i didn't get what do you think should be updated in the current
> fix? This is a regression fix. I just reverted part of the previous
> patch to fix the problem. And in all places I changed the whole desktop
> size should be used, not a primary monitor screen size. And
> Toolkit.getScreenSize() has been always returning the whole desktop.
> If you think that Toolkit.getScreenSize() should be changed to return
> the monitor-1 size, I don't mind to file a separate bug. I'm sure it
> will require to revise a lot of usages of the method including those
> you've mentioned. Probably, it will cause compatibility issues and will
> not be approved then. So, how is that related to the current fix?

The current bug in popup menu is that it relied on the incorrect 
behavior of the toolkit method, which right now returns the size of the 
virtual screen(and returns something strange in case of HiDPI+nonHiDPi 
screens).


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 18:07:02 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 21:07:02 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
Message-ID: <ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>



On 23.09.2016 20:52, Sergey Bylokhov wrote:
> On 23.09.16 20:40, Semyon Sadetsky wrote:
>>> Screen in our specification is a our own term. We have GraphicsDevice
>>> per screen. We have s special notion about "combined virtual screen"
>>> which "share the same coordinate system". Our methods and
>>> specification are not depends from the native WM implementation. In
>>> the current discussion toolkit should return the bounds of the primary
>>> screen which is default GraphicsDevice. So in the current fix the code
>>> related to popup menu should be updated. The new bug should be filed
>>> against toolkit.
>> Sorry, i didn't get what do you think should be updated in the current
>> fix? This is a regression fix. I just reverted part of the previous
>> patch to fix the problem. And in all places I changed the whole desktop
>> size should be used, not a primary monitor screen size. And
>> Toolkit.getScreenSize() has been always returning the whole desktop.
>> If you think that Toolkit.getScreenSize() should be changed to return
>> the monitor-1 size, I don't mind to file a separate bug. I'm sure it
>> will require to revise a lot of usages of the method including those
>> you've mentioned. Probably, it will cause compatibility issues and will
>> not be approved then. So, how is that related to the current fix?
>
> The current bug in popup menu is that it relied on the incorrect 
> behavior of the toolkit method, which right now returns the size of 
> the virtual screen(and returns something strange in case of 
> HiDPI+nonHiDPi screens).
It is not clear yet that behavior of the toolkit method is incorrect. At 
least, that it will be changed in 9. Anyway, this is a separate issue.
Could you clarify about "HiDPI+nonHiDPi screens"? What did you get?

From Sergey.Bylokhov at oracle.com  Fri Sep 23 18:26:07 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 23 Sep 2016 21:26:07 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
Message-ID: <04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>

On 23.09.16 21:07, Semyon Sadetsky wrote:
>> The current bug in popup menu is that it relied on the incorrect
>> behavior of the toolkit method, which right now returns the size of
>> the virtual screen(and returns something strange in case of
>> HiDPI+nonHiDPi screens).
> It is not clear yet that behavior of the toolkit method is incorrect. At
> least, that it will be changed in 9. Anyway, this is a separate issue.
> Could you clarify about "HiDPI+nonHiDPi screens"? What did you get?

Just check what value will be returned if the system have two displays 
and each will have own scale, the result will be downscaled based on 
default config.
We have two bugs:
  - This bug is about menu related code, it should care about bounds of 
gc where these popup will be shown, it should not use the method which 
return the bounds of the primary screen. In current fix the location 
will be incorrect if Xinerama is disabled and menu will be shown on 
non-primary screen, if this screen have different scale from main display.
  - The toolkit method should be reworked.


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Fri Sep 23 18:39:19 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 23 Sep 2016 21:39:19 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
Message-ID: <911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>



On 23.09.2016 21:26, Sergey Bylokhov wrote:
> On 23.09.16 21:07, Semyon Sadetsky wrote:
>>> The current bug in popup menu is that it relied on the incorrect
>>> behavior of the toolkit method, which right now returns the size of
>>> the virtual screen(and returns something strange in case of
>>> HiDPI+nonHiDPi screens).
>> It is not clear yet that behavior of the toolkit method is incorrect. At
>> least, that it will be changed in 9. Anyway, this is a separate issue.
>> Could you clarify about "HiDPI+nonHiDPi screens"? What did you get?
>
> Just check what value will be returned if the system have two displays 
> and each will have own scale, the result will be downscaled based on 
> default config.
Did you really try this? Because I did not see any Linux within the 
supported ones that allows this. Would be nice if you could share info 
how to get different scales for two monitors.
> We have two bugs:
>  - This bug is about menu related code, it should care about bounds of 
> gc where these popup will be shown, it should not use the method which 
> return the bounds of the primary screen. In current fix the location 
> will be incorrect if Xinerama is disabled and menu will be shown on 
> non-primary screen, if this screen have different scale from main 
> display.
If Xinerama is disabled the method will return the primary screen size 
which is your favorite one.
>  - The toolkit method should be reworked.
It as an open question at least for 9. I can file a bug if you want.


From alexander.zvegintsev at oracle.com  Fri Sep 23 19:12:50 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 23 Sep 2016 22:12:50 +0300
Subject: <AWT Dev> [9] Review request for 8165619: Frame is not
 repainted if created in state=MAXIMIZED_BOTH on Unity
In-Reply-To: <2a6cfd77-3768-2969-87df-55a87ab614a1@oracle.com>
References: <2a6cfd77-3768-2969-87df-55a87ab614a1@oracle.com>
Message-ID: <958665af-797b-4843-47e6-f0d20950f26f@oracle.com>

Looks good to me.

--
Thanks,
Alexander.

On 23.09.2016 16:15, Semyon Sadetsky wrote:
> Hello,
>
> Please review fix for JDK9:
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8165619
>
> webrev: http://cr.openjdk.java.net/~ssadetsky/8165619/webrev.00/
>
> If frame is created in maximized the window extent property 
> notification is not send by WM. So, ConfigureNotify event is skipped 
> and the target frame doesn't receive notification about size and its 
> content is not repainted.  To handle this scenario the waiting for 
> window extents is canceled for maximized window and the extents are 
> specified when window state is changed back to normal.
>
> --Semyon
>


From alexander.zvegintsev at oracle.com  Fri Sep 23 19:56:08 2016
From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev)
Date: Fri, 23 Sep 2016 22:56:08 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for 8154434: Open the
 request focus methods of the java.awt.Component which accept
 FocusEvent.Cause
In-Reply-To: <571F69C2.9010104@oracle.com>
References: <5715FABE.7050109@oracle.com> <571E711D.1060505@oracle.com>
	<571F1869.1040004@oracle.com> <571F63E3.8080908@oracle.com>
	<571F69C2.9010104@oracle.com>
Message-ID: <59a4cb07-bd29-beb5-7bfe-b5b0d7869dbe@oracle.com>

Looks good to me.

--
Thanks,
Alexander.

On 26.04.2016 16:14, Semyon Sadetsky wrote:
>
>
> On 4/26/2016 3:49 PM, Philip Race wrote:
>> > In applications one may need to know the reason why focus is requested
>>
>> I do not mean why should apps want to *know* the cause.
>>
>> I am asking why apps should be able to *specify* the cause as
>> proposed by this change.
>>
>> Being "symmetric" is not a sufficient reason.
> I just clarified that there are no a lot of needs for apps here.
> But if a framework is developed it may require to develop a custom 
> implementation of KeyboardFocusManager, for example. Such KFM may 
> simply override any logic that uses focus cause.
> Just from general consideration: JFC have been made open for extensions.
>
> --Semyon
>>
>> -phil.
>>
>> On 4/26/16, 12:27 AM, Semyon Sadetsky wrote:
>>> On 4/25/2016 10:33 PM, Phil Race wrote:
>>>> You will need to convince me of the appropriateness of opening 
>>>> these methods.
>>>> It seems to me that are for the focus system, not for applications.
>>>>
>>>> Why should an application be allowed to say "I would like component 
>>>> X" to
>>>> receive focus and tell it the reason is a mouse event" when in fact 
>>>> it is nothing of the kind.
>>> This is a continuation of the 8080395. I think it would be mostly 
>>> interesting for framework developers not for applications.
>>> In applications one may need to know the reason why focus is 
>>> requested to the component before the focus is set to it.
>>> As I heard from Anton (that was his task initially) opening the 
>>> cause was requested by some client, but, unfortunately, I don't have 
>>> any references.
>>>
>>> --Semyon
>>>>
>>>> I would like to hear from others if they see a valid use case and 
>>>> that there are no
>>>> down-sides to mis-use.
>>>>
>>>> -phil.
>>>>
>>>> On 04/19/2016 02:30 AM, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please review fix for JDK9:
>>>>>
>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8154434
>>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8154434/webrev.00/
>>>>>
>>>>> To support the new FocusEvent cause concept introduced by 
>>>>> JDK-8080395 the next package-private methods of the 
>>>>> java.awt.Component class are opened in the fix:
>>>>>
>>>>> boolean requestFocus(FocusEvent.Cause cause)  -> public void 
>>>>> requestFocus(FocusEvent.Cause cause)
>>>>>
>>>>> boolean requestFocus(boolean temporary, FocusEvent.Cause cause) -> 
>>>>> protected boolean requestFocus(boolean temporary, FocusEvent.Cause 
>>>>> cause)
>>>>>
>>>>> boolean requestFocusInWindow(FocusEvent.Cause cause) -> public 
>>>>> boolean requestFocusInWindow(FocusEvent.Cause cause)
>>>>>
>>>>> The methods are changed to be symmetric with the focus request 
>>>>> methods of the same class which do not accept the cause parameter.
>>>>> The method requestFocus(FocusEvent.Cause cause) was changed to 
>>>>> return no value similarly to the requestFocus() because the 
>>>>> returning boolean true cannot guarantee the focus gain.
>>>>>
>>>>> --Semyon
>>>>>
>>>>>
>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160923/e50bd99d/attachment-0001.html>

From philip.race at oracle.com  Sun Sep 25 00:04:29 2016
From: philip.race at oracle.com (Philip Race)
Date: Sat, 24 Sep 2016 17:04:29 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
Message-ID: <57E7148D.1090803@oracle.com>

   94     KeySym *key_syms = XGetKeyboardMapping(display, keycode, index + 1,&num_syms);


I might be mis-reading the API but the docs as I read it have argument 3
as a count .. so it should be 1 here, should it not ?

https://tronche.com/gui/x/xlib/input/XGetKeyboardMapping.html

As written I have a suspicion you will at some point run into an X 
BadValue error

The docs say :-
"In addition, the following expression must be less than or equal
to max_keycode as returned by XDisplayKeycodes():

     first_keycode + keycode_count - 1
"

To be truly robust here we should somewhere obtain and probably cache
"first key code" and max_keycode.

https://tronche.com/gui/x/xlib/input/XDisplayKeycodes.html
I say cache since you don't want two X calls every time.

Then if the requested code is outside that ... just return NoSymbol I 
suppose.

Furthermore

KeySym ks = key_syms[index];


then looks very wrong. You want "0" here .. not index, don't you?
So I must be completely misunderstanding this X API if this is working 
for you.

I am also a bit unclear how we know that the first keysym listed for the
keycode from the list is the one we want ?

-phil.

On 9/14/16, 10:42 AM, Alan Burlison wrote:
> On 06/09/2016 11:16, Alan Burlison wrote:
>
>> XKeycodeToKeysym is deprecated and when compiled on Solaris 12 with
>> warnings-as-errors this causes a compile time failure. References to
>> XKeycodeToKeysym should be replaced by XkbKeycodeToKeysym. As this is
>> common XOrg code it will affect Linux as well.
>>
>> Bug:    https://bugs.openjdk.java.net/browse/JDK-8165232
>> Webrev: http://cr.openjdk.java.net/~alanbur/JDK-8165232/
>
> I've respun this and replaced the calls to XKeycodeToKeysym with 
> equivalent code that uses XGetKeyboardMapping instead. This addresses 
> the problem without introducing a dependency on XKEYBOARD, which I 
> think is is a better fix.
>
> I'd appreciate any review comments.
>
> Thanks,
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160924/62a2acc1/attachment.html>

From malenkov at gmail.com  Sun Sep 25 22:38:14 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Mon, 26 Sep 2016 01:38:14 +0300
Subject: <AWT Dev> MacOS: precise scrolling is too fast
Message-ID: <CANTFZ2j4uKEgybd7Z0k48+yOrSvikCRMFuN-rTADzGbemRg=aw@mail.gmail.com>

Hi guys,

JetBrains has some problems to continue Oracle support, and I have no
ability to submit a CR for now.  But there is a critical issue in AWT
scrolling after Sierra have been released.
http://bugs.openjdk.java.net/browse/JDK-8166591

I solved this issue in our custom JDK:
http://sites.google.com/site/malenkov/java/160926

This fix is safe for existing third-party code, but it removes support
of precise scrolling. It is OK for now, because Swing does not support
it. I can provide another fix, but it may affect third-party
developers and requires additional changes in Swing. For example, the
following bug must be fixed in another way:
http://bugs.openjdk.java.net/browse/JDK-7141296
I think there are may be other issues, but I have not access to
test/closed repository to check this. Could you please move UI tests
to open-source like I did for java.beans?


I see the following steps to do:
1. fix 8166591 for comfortable scrolling in Sierra
- apply my fix (simple and almost safe) or update it
  to restore precise scrolling and fix all usages of MouseWheelEvent
2. implement new feature: Precise scrolling in Swing
- now it uses integers only
3. implement new feature: Imitate native scroll bars on Mac


I'll try to raise the issue severity as soon as we restore access to
Oracle support.

-- 
Best regards,
Sergey A. Malenkov

From victor.dyakov at oracle.com  Mon Sep 26 02:57:28 2016
From: victor.dyakov at oracle.com (Victor D'yakov)
Date: Sun, 25 Sep 2016 19:57:28 -0700
Subject: <AWT Dev> MacOS: precise scrolling is too fast
In-Reply-To: <CANTFZ2j4uKEgybd7Z0k48+yOrSvikCRMFuN-rTADzGbemRg=aw@mail.gmail.com>
References: <CANTFZ2j4uKEgybd7Z0k48+yOrSvikCRMFuN-rTADzGbemRg=aw@mail.gmail.com>
Message-ID: <e34cdaa7-98ee-8708-247f-fc151600a499@oracle.com>

Sergey, Thanks.

Alexandr, please look at this P2 high priority issue. It seems we need a 
quick turnover as affecting anyone switched on Sierra Mac OS 10.12 release.

Thanks,
Victor
On 9/25/2016 3:38 PM, Sergey Malenkov wrote:
> Hi guys,
>
> JetBrains has some problems to continue Oracle support, and I have no
> ability to submit a CR for now.  But there is a critical issue in AWT
> scrolling after Sierra have been released.
> http://bugs.openjdk.java.net/browse/JDK-8166591
>
> I solved this issue in our custom JDK:
> http://sites.google.com/site/malenkov/java/160926
>
> This fix is safe for existing third-party code, but it removes support
> of precise scrolling. It is OK for now, because Swing does not support
> it. I can provide another fix, but it may affect third-party
> developers and requires additional changes in Swing. For example, the
> following bug must be fixed in another way:
> http://bugs.openjdk.java.net/browse/JDK-7141296
> I think there are may be other issues, but I have not access to
> test/closed repository to check this. Could you please move UI tests
> to open-source like I did for java.beans?
>
>
> I see the following steps to do:
> 1. fix 8166591 for comfortable scrolling in Sierra
> - apply my fix (simple and almost safe) or update it
>    to restore precise scrolling and fix all usages of MouseWheelEvent
> 2. implement new feature: Precise scrolling in Swing
> - now it uses integers only
> 3. implement new feature: Imitate native scroll bars on Mac
>
>
> I'll try to raise the issue severity as soon as we restore access to
> Oracle support.
>


From Alan.Burlison at oracle.com  Mon Sep 26 16:53:29 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 26 Sep 2016 17:53:29 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <57E7148D.1090803@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
Message-ID: <8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>

On 25/09/2016 01:04, Philip Race wrote:

>   94     KeySym *key_syms = XGetKeyboardMapping(display, keycode, index
> + 1,&num_syms);
>
> I might be mis-reading the API but the docs as I read it have argument 3
> as a count .. so it should be 1 here, should it not ?
>
> https://tronche.com/gui/x/xlib/input/XGetKeyboardMapping.html

I think you are right, I was reading the third parameter as being the 
number of keysyms to be returned, whereas it is the number of keycodes, 
starting with the one passed in argument 2, that are to be returned. In 
that case yes, 1 would seem to be the correct value. I've made that change,

> As written I have a suspicion you will at some point run into an X
> BadValue error
>
> The docs say :-
> "In addition, the following expression must be less than or equal
> to max_keycode as returned by XDisplayKeycodes():
>
>     first_keycode + keycode_count - 1
> "
>
> To be truly robust here we should somewhere obtain and probably cache
> "first key code" and max_keycode.
>
> https://tronche.com/gui/x/xlib/input/XDisplayKeycodes.html
> I say cache since you don't want two X calls every time.
>
> Then if the requested code is outside that ... just return NoSymbol I
> suppose.

Yes, I think you'll get a BadValue error. It appears that under those 
conditions the original call to XKeycodeToKeysym will return NoSymbol, 
so doing the same seems best. Also it would probably make sense to add 
range checking to the index parameter as well.

I've updated the webrev with the above suggestions.

> Furthermore
>
> KeySym ks = key_syms[index];
>
> then looks very wrong. You want "0" here .. not index, don't you?
> So I must be completely misunderstanding this X API if this is working
> for you.
>
> I am also a bit unclear how we know that the first keysym listed for the
> keycode from the list is the one we want ?

I think 'index' is right once 1 is provided as the third parameter to 
XGetKeyboardMapping as what is coming back is an array of keysyms.

I'd run the original code through the JDK testuite and it passed, if you 
have any suggestions how better to test this I'd be grateful to hear them.

Thanks,

-- 
Alan Burlison
--

From Sergey.Bylokhov at oracle.com  Mon Sep 26 17:38:20 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Mon, 26 Sep 2016 20:38:20 +0300
Subject: <AWT Dev> [9] Review Request: 8166673 The new implementation of
 Robot.waitForIdle() may hang
Message-ID: <73586e81-9035-10b8-de87-0ab220ee5395@oracle.com>

Hello.

Please review the fix for jdk9.

The SunToolkit.waitForIdle() uses string literal for synchronization, 
which means some code (intentionally or not) can hang Robot.waitForIdle.

Bug: https://bugs.openjdk.java.net/browse/JDK-8166673
Webrev can be found at: http://cr.openjdk.java.net/~serb/8166673/webrev.00

-- 
Best regards, Sergey.

From philip.race at oracle.com  Mon Sep 26 22:01:09 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Sep 2016 15:01:09 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
Message-ID: <57E99AA5.1020704@oracle.com>

So that looks like it should work although the duplicate definition irks.
Can we remove the static and have it just be extern declared in XWindow.c ?

For testing can you submit a jprt job and I'll see if I can rustle up some
SQE support to identify any tests that might be good to run.

-phil.


On 9/26/16, 9:53 AM, Alan Burlison wrote:
> On 25/09/2016 01:04, Philip Race wrote:
>
>>   94     KeySym *key_syms = XGetKeyboardMapping(display, keycode, index
>> + 1,&num_syms);
>>
>> I might be mis-reading the API but the docs as I read it have argument 3
>> as a count .. so it should be 1 here, should it not ?
>>
>> https://tronche.com/gui/x/xlib/input/XGetKeyboardMapping.html
>
> I think you are right, I was reading the third parameter as being the 
> number of keysyms to be returned, whereas it is the number of 
> keycodes, starting with the one passed in argument 2, that are to be 
> returned. In that case yes, 1 would seem to be the correct value. I've 
> made that change,
>
>> As written I have a suspicion you will at some point run into an X
>> BadValue error
>>
>> The docs say :-
>> "In addition, the following expression must be less than or equal
>> to max_keycode as returned by XDisplayKeycodes():
>>
>>     first_keycode + keycode_count - 1
>> "
>>
>> To be truly robust here we should somewhere obtain and probably cache
>> "first key code" and max_keycode.
>>
>> https://tronche.com/gui/x/xlib/input/XDisplayKeycodes.html
>> I say cache since you don't want two X calls every time.
>>
>> Then if the requested code is outside that ... just return NoSymbol I
>> suppose.
>
> Yes, I think you'll get a BadValue error. It appears that under those 
> conditions the original call to XKeycodeToKeysym will return NoSymbol, 
> so doing the same seems best. Also it would probably make sense to add 
> range checking to the index parameter as well.
>
> I've updated the webrev with the above suggestions.
>
>> Furthermore
>>
>> KeySym ks = key_syms[index];
>>
>> then looks very wrong. You want "0" here .. not index, don't you?
>> So I must be completely misunderstanding this X API if this is working
>> for you.
>>
>> I am also a bit unclear how we know that the first keysym listed for the
>> keycode from the list is the one we want ?
>
> I think 'index' is right once 1 is provided as the third parameter to 
> XGetKeyboardMapping as what is coming back is an array of keysyms.
>
> I'd run the original code through the JDK testuite and it passed, if 
> you have any suggestions how better to test this I'd be grateful to 
> hear them.
>
> Thanks,
>

From Alan.Burlison at oracle.com  Mon Sep 26 22:09:36 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Mon, 26 Sep 2016 23:09:36 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <57E99AA5.1020704@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
Message-ID: <2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>

On 26/09/16 23:01, Philip Race wrote:

> So that looks like it should work although the duplicate definition irks.
> Can we remove the static and have it just be extern declared in XWindow.c ?

Absolutely - I didn't particularly like it either but I was a bit wary 
of adding a new external symbol. Is the current name OK?

> For testing can you submit a jprt job and I'll see if I can rustle up some
> SQE support to identify any tests that might be good to run.

Excellent, thank you :-) I've already run jprt with the core testset, 
I'll send you the notification mail separately. There were a couple of 
test failures but they didn't seem related to this change, although a 
pair of more experienced eyes would be good!

-- 
Alan Burlison
--

From philip.race at oracle.com  Mon Sep 26 22:42:08 2016
From: philip.race at oracle.com (Philip Race)
Date: Mon, 26 Sep 2016 15:42:08 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
Message-ID: <57E9A440.70708@oracle.com>



On 9/26/16, 3:09 PM, Alan Burlison wrote:
> On 26/09/16 23:01, Philip Race wrote:
>
>> So that looks like it should work although the duplicate definition 
>> irks.
>> Can we remove the static and have it just be extern declared in 
>> XWindow.c ?
>
> Absolutely - I didn't particularly like it either but I was a bit wary 
> of adding a new external symbol. Is the current name OK?
>
It isn't really external. we use mapfiles and so limit exports.
The name is OK by me.

>> For testing can you submit a jprt job and I'll see if I can rustle up 
>> some
>> SQE support to identify any tests that might be good to run.
>
> Excellent, thank you :-) I've already run jprt with the core testset, 
> I'll send you the notification mail separately. There were a couple of 
> test failures but they didn't seem related to this change, although a 
> pair of more experienced eyes would be good!
>
I'll look at that and send separate email.

-phil.


From manajit.halder at oracle.com  Tue Sep 27 08:51:21 2016
From: manajit.halder at oracle.com (Manajit Halder)
Date: Tue, 27 Sep 2016 14:21:21 +0530
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
	VM crashes on second attempt to execute JCK interactive tests
	that use Robot (single JVM, agent)
In-Reply-To: <53d96f6e-0809-13bb-099e-396c611bdf4b@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
	<E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
	<53d96f6e-0809-13bb-099e-396c611bdf4b@oracle.com>
Message-ID: <C4D3CB16-93F1-4696-967C-EA3F439AA84D@oracle.com>

Hi Sergey,

Thanks for the comment. ?self.javaToMacKeyMap is retaining the reference.
Please review the modified code:

http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/>

Thanks,
Manajit

> On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> On 21.09.16 16:01, Manajit Halder wrote:
>> Hi Sergey,
>> 
>> Thanks for the comment.
>> 
>> Access to "instance" is not broken. The problem is with the dictionary
>> variable "javaToMacKeyMap" within the "instance" reference.
>> The dictionary is not getting initialised for the second time when
>> singleton method is called for the second time. The dictionary is
>> getting initialised during the first time singleton method is called and
>> hence crash was observed. Tried adding self.javaToMacKeyMap
>> but doesn?t solve the problem.
> 
> I still suggest you to check "self.javaToMacKeyMap" at line 48 this should call generated setter which will retain the reference.
> 
>> 
>> I propose two solutions to this problem:
>> 
>> Solution 1:
>> Reinitialise the dictionary every-time the singleton method is called.
>> Webrev:
>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>> 
>> Drawback:
>> dictionary is initialised multiple times (every time singleton method is
>> called).
>> 
>> Solution 2:
>> Make the dictionary static.
>> Drawback:
>> Still dictionary need to be initialised multiple times.
>> No singleton method, just two static methods, one method to initialise
>> the dictionary and other to get the key form the dictionary.
>> Webrev:
>> Not prepared. Will be prepared if second solution accepted.
>> 
>> Test case:
>> There are no test cases. Problem can be reproduced by
>> executing following JCK test:
>> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
>> "api/java_awt/interactive/event/EventTests.html#EventTest0019
>> api/java_awt/interactive/event/EventTests.html#EventTest0013?
>> 
>> Thanks,
>> Manajit
>> 
>>> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>>> wrote:
>>> 
>>> Hi, Manajit.
>>> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
>>> returns the new object per invocation, so it is not really
>>> sharedInstance. I am not sure I understand what is wrong in the
>>> current code, from the my point of view this is a correct singleton.
>>> It it true that the problem is in access to broken "instance" and not
>>> to "javaToMacKeyMap" inside the "instance"? If not then
>>> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
>>> Do you have a test case to reproduce the bug?
>>> 
>>> On 19.09.16 15:26, Manajit Halder wrote:
>>>> Hi All,
>>>> 
>>>> Kindly review the fix for JDK9.
>>>> 
>>>> Bug:
>>>> https://bugs.openjdk.java.net/browse/JDK-8165555 <https://bugs.openjdk.java.net/browse/JDK-8165555>
>>>> 
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/ <http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/>
>>>> 
>>>> Issue:
>>>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>>>> that use Robot (single JVM, agent)
>>>> 
>>>> Cause:
>>>> While executing the JCK test for the second time the robot was getting
>>>> initialised once again and old instance of CRobotKeyCodeMapping was not
>>>> available.
>>>> Crash was observed while trying to access invalid instance of
>>>> CRobotKeyCodeMapping.
>>>> 
>>>> Fix:
>>>> A new instance of CRobotKeyCodeMapping is created when robot is
>>>> initialised.
>>>> 
>>>> Regards,
>>>> Manajit
>>> 
>>> 
>>> --
>>> Best regards, Sergey.
>> 
> 
> 
> -- 
> Best regards, Sergey.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160927/f36ac5f1/attachment.html>

From Sergey.Bylokhov at oracle.com  Tue Sep 27 10:45:23 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 27 Sep 2016 13:45:23 +0300
Subject: <AWT Dev> <AWT dev>[9] Review request for JDK-8165555: [macosx]
 VM crashes on second attempt to execute JCK interactive tests that use
 Robot (single JVM, agent)
In-Reply-To: <C4D3CB16-93F1-4696-967C-EA3F439AA84D@oracle.com>
References: <73C55A8D-433F-4315-9FBF-0893E5572015@oracle.com>
	<571f1b1f-f94f-bd7c-ce55-50b2af669e4e@oracle.com>
	<E3329562-36CC-41F9-9490-8CD7B33736DD@oracle.com>
	<53d96f6e-0809-13bb-099e-396c611bdf4b@oracle.com>
	<C4D3CB16-93F1-4696-967C-EA3F439AA84D@oracle.com>
Message-ID: <d90213a4-5713-5e2c-2a82-863445cc1780@oracle.com>

On 27.09.16 11:51, Manajit Halder wrote:
> Hi Sergey,
>
> Thanks for the comment. ?self.javaToMacKeyMap is retaining the reference.
> Please review the modified code:
>
> http://cr.openjdk.java.net/~mhalder/8165555/webrev.02/

The changes in CRobot.m is unnecessary? I also suggest to write the 
test. Recently I have run all jck tests on my osx system and no of them 
were crashed, so it seems that the sequence of tests in the bug report 
are not stable and the new reg test will be welcome to catch such bugs 
always.

>> On 23-Sep-2016, at 10:24 pm, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com <mailto:Sergey.Bylokhov at oracle.com>> wrote:
>>
>> On 21.09.16 16:01, Manajit Halder wrote:
>>> Hi Sergey,
>>>
>>> Thanks for the comment.
>>>
>>> Access to "instance" is not broken. The problem is with the dictionary
>>> variable "javaToMacKeyMap" within the "instance" reference.
>>> The dictionary is not getting initialised for the second time when
>>> singleton method is called for the second time. The dictionary is
>>> getting initialised during the first time singleton method is called and
>>> hence crash was observed. Tried adding self.javaToMacKeyMap
>>> but doesn?t solve the problem.
>>
>> I still suggest you to check "self.javaToMacKeyMap" at line 48 this
>> should call generated setter which will retain the reference.
>>
>>>
>>> I propose two solutions to this problem:
>>>
>>> Solution 1:
>>> Reinitialise the dictionary every-time the singleton method is called.
>>> Webrev:
>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.01/
>>>
>>> Drawback:
>>> dictionary is initialised multiple times (every time singleton method is
>>> called).
>>>
>>> Solution 2:
>>> Make the dictionary static.
>>> Drawback:
>>> Still dictionary need to be initialised multiple times.
>>> No singleton method, just two static methods, one method to initialise
>>> the dictionary and other to get the key form the dictionary.
>>> Webrev:
>>> Not prepared. Will be prepared if second solution accepted.
>>>
>>> Test case:
>>> There are no test cases. Problem can be reproduced by
>>> executing following JCK test:
>>> java -jar JCK-runtime-9/lib/jtjck.jar -mode:single -k:interactive
>>> "api/java_awt/interactive/event/EventTests.html#EventTest0019
>>> api/java_awt/interactive/event/EventTests.html#EventTest0013?
>>>
>>> Thanks,
>>> Manajit
>>>
>>>> On 20-Sep-2016, at 4:42 am, Sergey Bylokhov
>>>> <Sergey.Bylokhov at oracle.com
>>>> <mailto:Sergey.Bylokhov at oracle.com> <mailto:Sergey.Bylokhov at oracle.com>>
>>>> wrote:
>>>>
>>>> Hi, Manajit.
>>>> It seems that after the fix "(CRobotKeyCodeMapping *) sharedInstance"
>>>> returns the new object per invocation, so it is not really
>>>> sharedInstance. I am not sure I understand what is wrong in the
>>>> current code, from the my point of view this is a correct singleton.
>>>> It it true that the problem is in access to broken "instance" and not
>>>> to "javaToMacKeyMap" inside the "instance"? If not then
>>>> "javaToMacKeyMap" should be changed to "self.javaToMacKeyMap".
>>>> Do you have a test case to reproduce the bug?
>>>>
>>>> On 19.09.16 15:26, Manajit Halder wrote:
>>>>> Hi All,
>>>>>
>>>>> Kindly review the fix for JDK9.
>>>>>
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8165555
>>>>>
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~mhalder/8165555/webrev.00/
>>>>>
>>>>> Issue:
>>>>> [macosx] VM crashes on second attempt to execute JCK interactive tests
>>>>> that use Robot (single JVM, agent)
>>>>>
>>>>> Cause:
>>>>> While executing the JCK test for the second time the robot was getting
>>>>> initialised once again and old instance of CRobotKeyCodeMapping was not
>>>>> available.
>>>>> Crash was observed while trying to access invalid instance of
>>>>> CRobotKeyCodeMapping.
>>>>>
>>>>> Fix:
>>>>> A new instance of CRobotKeyCodeMapping is created when robot is
>>>>> initialised.
>>>>>
>>>>> Regards,
>>>>> Manajit
>>>>
>>>>
>>>> --
>>>> Best regards, Sergey.
>>>
>>
>>
>> --
>> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From peter.brunet at oracle.com  Tue Sep 27 12:57:01 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 27 Sep 2016 07:57:01 -0500
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <bd326ed9-f58b-0473-97e8-92bd4218f749@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
	<e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
	<ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>
	<bd326ed9-f58b-0473-97e8-92bd4218f749@jetbrains.com>
Message-ID: <48e9f56b-b5a6-f386-37a7-a01b9662b675@oracle.com>

Anton, It looks like you need to also update getInitialAttributeStates. 
-Pete

On 9/16/16 12:49 PM, Anton Tarasov wrote:
> On 9/16/2016 1:32 PM, Sergey Bylokhov wrote:
>> On 15.09.16 14:48, Anton Tarasov wrote:
>>>> Yes, and my suggestion was to use the new method and default values
>>>> everywhere instead of invokeAndWait(Callable,Component).
>>>
>>> But the default value for a reference would be null, there's no need to
>>> request something else, unlike for primitive wrappers.
>>>
>>> Or your idea is to force passing a def value anyway?
>>
>> If the references like Point from getLocationOnScreen() can be null,
>> then ok. looks fine.
>
> Yes, it can.
>
> Anton.
>
>>
>>>
>>> Anton.
>>>
>>>>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the fix:
>>>>>>>
>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>>>>
>>>>>>> (The bug is currently closed as ?not an issue?, which is not quite
>>>>>>> true.
>>>>>>> So once and if the fix is approved I can take the ownership of the
>>>>>>> bug).
>>>>>>>
>>>>>>> The problem is this. Sometimes when a frame is closed there may
>>>>>>> appear a
>>>>>>> race condition:
>>>>>>>
>>>>>>> - removeNotify() is called on the frame on EDT and it removes
>>>>>>> all the
>>>>>>> events associated with the frame from the event queue.
>>>>>>>
>>>>>>> - The frame is requested by accessibility via the CAccessibility
>>>>>>> static
>>>>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those
>>>>>>> methods
>>>>>>> are called from native on AppKit thread and they perform via
>>>>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>>>>> source is set to the frame. But, once the event is put on the event
>>>>>>> queue, it's purged by the removeNotify() call. As the result,
>>>>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results
>>>>>>> in NPE
>>>>>>> propagated to native. On the native side, the NPE is not properly
>>>>>>> handled and is just re-thrown.
>>>>>>>
>>>>>>> I don't have a simple and safe solution for the race. So, I
>>>>>>> suggest to
>>>>>>> fix the NPE/crash at least.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Anton.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From anton.tarasov at jetbrains.com  Tue Sep 27 13:37:54 2016
From: anton.tarasov at jetbrains.com (Anton Tarasov)
Date: Tue, 27 Sep 2016 16:37:54 +0300
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
	crashes with NPE at
	sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <48e9f56b-b5a6-f386-37a7-a01b9662b675@oracle.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
	<e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
	<ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>
	<bd326ed9-f58b-0473-97e8-92bd4218f749@jetbrains.com>
	<48e9f56b-b5a6-f386-37a7-a01b9662b675@oracle.com>
Message-ID: <C9861877-2F9A-45A5-8817-73D5970FA6E7@jetbrains.com>

But it returns an array which is an object and you don?t have the original unboxing issue.

Anton.

> On 27 Sep 2016, at 15:57, Pete Brunet <peter.brunet at oracle.com> wrote:
> 
> Anton, It looks like you need to also update getInitialAttributeStates. 
> -Pete
> 
> On 9/16/16 12:49 PM, Anton Tarasov wrote:
>> On 9/16/2016 1:32 PM, Sergey Bylokhov wrote:
>>> On 15.09.16 14:48, Anton Tarasov wrote:
>>>>> Yes, and my suggestion was to use the new method and default values
>>>>> everywhere instead of invokeAndWait(Callable,Component).
>>>> 
>>>> But the default value for a reference would be null, there's no need to
>>>> request something else, unlike for primitive wrappers.
>>>> 
>>>> Or your idea is to force passing a def value anyway?
>>> 
>>> If the references like Point from getLocationOnScreen() can be null,
>>> then ok. looks fine.
>> 
>> Yes, it can.
>> 
>> Anton.
>> 
>>> 
>>>> 
>>>> Anton.
>>>> 
>>>>>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>>>>>> Hello,
>>>>>>>> 
>>>>>>>> Please review the fix:
>>>>>>>> 
>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>>>>> 
>>>>>>>> (The bug is currently closed as ?not an issue?, which is not quite
>>>>>>>> true.
>>>>>>>> So once and if the fix is approved I can take the ownership of the
>>>>>>>> bug).
>>>>>>>> 
>>>>>>>> The problem is this. Sometimes when a frame is closed there may
>>>>>>>> appear a
>>>>>>>> race condition:
>>>>>>>> 
>>>>>>>> - removeNotify() is called on the frame on EDT and it removes
>>>>>>>> all the
>>>>>>>> events associated with the frame from the event queue.
>>>>>>>> 
>>>>>>>> - The frame is requested by accessibility via the CAccessibility
>>>>>>>> static
>>>>>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those
>>>>>>>> methods
>>>>>>>> are called from native on AppKit thread and they perform via
>>>>>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>>>>>> source is set to the frame. But, once the event is put on the event
>>>>>>>> queue, it's purged by the removeNotify() call. As the result,
>>>>>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>>>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results
>>>>>>>> in NPE
>>>>>>>> propagated to native. On the native side, the NPE is not properly
>>>>>>>> handled and is just re-thrown.
>>>>>>>> 
>>>>>>>> I don't have a simple and safe solution for the race. So, I
>>>>>>>> suggest to
>>>>>>>> fix the NPE/crash at least.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Anton.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>> 
> 


From peter.brunet at oracle.com  Tue Sep 27 13:43:46 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 27 Sep 2016 08:43:46 -0500
Subject: <AWT Dev> Review request for 8165829: Android Studio 2.x
 crashes with NPE at
 sun.lwawt.macosx.CAccessibility.getAccessibleIndexInParent
In-Reply-To: <C9861877-2F9A-45A5-8817-73D5970FA6E7@jetbrains.com>
References: <5B00B286-1724-439E-8D01-5F0E222F9430@jetbrains.com>
	<9dcefe89-e815-f8f9-e8b5-1666efa8f03e@oracle.com>
	<69bf42e2-fab7-7bac-dcf0-509b2e10fb0e@jetbrains.com>
	<594d5299-d9ad-d495-83fe-88ebfa914edf@oracle.com>
	<e022bb73-8d71-48db-dda3-3827df5e25c8@jetbrains.com>
	<ce0d2d22-e423-dd36-a542-06e1cdeca9a3@oracle.com>
	<bd326ed9-f58b-0473-97e8-92bd4218f749@jetbrains.com>
	<48e9f56b-b5a6-f386-37a7-a01b9662b675@oracle.com>
	<C9861877-2F9A-45A5-8817-73D5970FA6E7@jetbrains.com>
Message-ID: <158e255f-f7b7-fc0e-9686-a0c0ed872c73@oracle.com>

OK.  Looks good then.

On 9/27/16 8:37 AM, Anton Tarasov wrote:
> But it returns an array which is an object and you don?t have the original unboxing issue.
>
> Anton.
>
>> On 27 Sep 2016, at 15:57, Pete Brunet <peter.brunet at oracle.com> wrote:
>>
>> Anton, It looks like you need to also update getInitialAttributeStates. 
>> -Pete
>>
>> On 9/16/16 12:49 PM, Anton Tarasov wrote:
>>> On 9/16/2016 1:32 PM, Sergey Bylokhov wrote:
>>>> On 15.09.16 14:48, Anton Tarasov wrote:
>>>>>> Yes, and my suggestion was to use the new method and default values
>>>>>> everywhere instead of invokeAndWait(Callable,Component).
>>>>> But the default value for a reference would be null, there's no need to
>>>>> request something else, unlike for primitive wrappers.
>>>>>
>>>>> Or your idea is to force passing a def value anyway?
>>>> If the references like Point from getLocationOnScreen() can be null,
>>>> then ok. looks fine.
>>> Yes, it can.
>>>
>>> Anton.
>>>
>>>>> Anton.
>>>>>
>>>>>>>> On 15.09.16 12:45, Anton Tarasov wrote:
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> Please review the fix:
>>>>>>>>>
>>>>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8165829
>>>>>>>>> webrev: http://cr.openjdk.java.net/~ant/JDK-8165829/jdk9/webrev.0
>>>>>>>>>
>>>>>>>>> (The bug is currently closed as ?not an issue?, which is not quite
>>>>>>>>> true.
>>>>>>>>> So once and if the fix is approved I can take the ownership of the
>>>>>>>>> bug).
>>>>>>>>>
>>>>>>>>> The problem is this. Sometimes when a frame is closed there may
>>>>>>>>> appear a
>>>>>>>>> race condition:
>>>>>>>>>
>>>>>>>>> - removeNotify() is called on the frame on EDT and it removes
>>>>>>>>> all the
>>>>>>>>> events associated with the frame from the event queue.
>>>>>>>>>
>>>>>>>>> - The frame is requested by accessibility via the CAccessibility
>>>>>>>>> static
>>>>>>>>> methods (like CAccessibility.getAccessibleIndexInParent). Those
>>>>>>>>> methods
>>>>>>>>> are called from native on AppKit thread and they perform via
>>>>>>>>> invokeAndWait. The latter is wrapped with an InvocationEvent whose
>>>>>>>>> source is set to the frame. But, once the event is put on the event
>>>>>>>>> queue, it's purged by the removeNotify() call. As the result,
>>>>>>>>> invokeAndWait returns null. Then, in some of the mentioned methods
>>>>>>>>> 'null' is unboxed to a primitive 'int' or 'boolean' which results
>>>>>>>>> in NPE
>>>>>>>>> propagated to native. On the native side, the NPE is not properly
>>>>>>>>> handled and is just re-thrown.
>>>>>>>>>
>>>>>>>>> I don't have a simple and safe solution for the race. So, I
>>>>>>>>> suggest to
>>>>>>>>> fix the NPE/crash at least.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Anton.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>


From Alan.Burlison at oracle.com  Tue Sep 27 15:41:56 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Tue, 27 Sep 2016 16:41:56 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <57E9A440.70708@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
Message-ID: <0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>

On 26/09/2016 23:42, Philip Race wrote:


>>> So that looks like it should work although the duplicate
>>> definition irks. Can we remove the static and have it just be
>>> extern declared in XWindow.c ?
>>
>> Absolutely - I didn't particularly like it either but I was a bit
>> wary of adding a new external symbol. Is the current name OK?

Done, new webrev at http://cr.openjdk.java.net/~alanbur/JDK-8165232.v2/

>>> For testing can you submit a jprt job and I'll see if I can
>>> rustle up some SQE support to identify any tests that might be
>>> good to run.

JPRT run on the v2 patch is clean.

-- 
Alan Burlison
--

From Sergey.Bylokhov at oracle.com  Tue Sep 27 16:09:54 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Tue, 27 Sep 2016 19:09:54 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8132664:
 closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on
 Windows
In-Reply-To: <55C0A7EF.80809@oracle.com>
References: <55BF7A25.50301@oracle.com> <55BF8354.7060200@oracle.com>
	<55C0A7EF.80809@oracle.com>
Message-ID: <16096f2e-ba45-31cf-c322-0668239e931d@oracle.com>

On 04.08.15 14:54, Semyon Sadetsky wrote:
> On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
>> Hi, Semyon
>> Did you try to change dwMilliseconds from INFINITE to the timeout(10
>> seconds by default?) which is passed to the method? It does not help?
>> Because even when dnd is not used we should not wait event for
>> infinite time.
> It would not help to fix the issue because 10 seconds is too big
> interval. But for consistency it is not bad to have a time limit.
> http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.01/

Looks fine. Please file separate issue that syncNativeQueue() should 
check that dnd callbacks are started/completed, because "(newEventNumber 
- eventNumber) > 2" check is useless if we are in the DND. And if some 
callbacks are in progress syncNativeQueue() should notify the java side 
that we should call syncNativeQueue() one more time.

>
>>
>> On 03.08.15 17:26, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please review fix for JDK9:
>>>
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132664
>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.00/
>>>
>>> DoDragDrop() is blocking, so upon drag operation is triggered the
>>> toolkit thread is blocked and the WM_AWT_WAIT cannot be processed
>>> which in its turn blocks the AWT robot.
>>> The solution is to escape AWT robot waiting in syncNativeQueue() if
>>> drag operation is in progress.
>>>
>>> --Semyon
>>
>>
>


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Wed Sep 28 17:16:20 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 28 Sep 2016 21:16:20 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
Message-ID: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>


Hello,

Could you review the fix:
   bug: https://bugs.openjdk.java.net/browse/JDK-8166591
   webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02

   This issue has been risen and investigated by JetBrains team in the 
email:
http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html

   MacOS Sierra 10.12 sends many scroll events with values close to zero 
when the trackpad is used. The small scroll values are rounded to +1 or 
-1 so one line scroll would be possible. It leads that many small scroll 
events causes fast scrolling.

   The proposed fix accumulates scroll values from the trackpad until 
they exceed some threshold  values. Only after that 
MouseWheelEvent.wheelRotation value is set. Mouse wheel scroll events 
are handled as before, small values are just rounded to + or -1.

   Thanks,
   Alexandr.

From alexandr.scherbatiy at oracle.com  Wed Sep 28 17:22:06 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Wed, 28 Sep 2016 21:22:06 +0400
Subject: <AWT Dev> RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are
 not accessible
In-Reply-To: <3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com>
References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com>
	<99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com>
	<3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com>
Message-ID: <a0a7ef8f-d5cb-4bde-e8da-bff1bd77924a@oracle.com>

The fix looks good to me.

I have also added awt-dev alias because fix changes the native part.

Thanks,
Alexandr.

On 26/09/16 16:22, Anton Tarasov wrote:
> Hi Pete,
>
> The fix looks fine to me.
>
> Thanks,
> Anton.
>
> On 9/24/2016 2:59 AM, Pete Brunet wrote:
>> New webrev:
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/
>>
>> I added a null check at line 688 like the one at line 693.
>>
>> Pete
>>
>> On 9/23/16 2:46 PM, Pete Brunet wrote:
>>> Please review the patch for JDK-8160893.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160893
>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/
>>>
>>> This patch adds support to post menu related events:
>>> kAXMenuOpenedNotification, kAXMenuClosedNotification, and
>>> kAXMenuItemSelectedNotification.  Also note that these changes had
>>> impacts on the current combo box behavior so you'll see combo boxes
>>> filtered out from this fix.  The combo box behavior is currently broken
>>> and will be fixed at a later date but at least for now I didn't want
>>> this patch to change that (broken) behavior.
>>>
>>> TiA,
>>> Pete
>


From Sergey.Bylokhov at oracle.com  Wed Sep 28 19:54:34 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 28 Sep 2016 22:54:34 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
Message-ID: <07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>

On 23.09.16 21:39, Semyon Sadetsky wrote:
>> Just check what value will be returned if the system have two displays
>> and each will have own scale, the result will be downscaled based on
>> default config.
> Did you really try this? Because I did not see any Linux within the
> supported ones that allows this. Would be nice if you could share info
> how to get different scales for two monitors.

It is not necessary to check, it is obvious from the code. It is broken 
in this case.

>> We have two bugs:
>>  - This bug is about menu related code, it should care about bounds of
>> gc where these popup will be shown, it should not use the method which
>> return the bounds of the primary screen. In current fix the location
>> will be incorrect if Xinerama is disabled and menu will be shown on
>> non-primary screen, if this screen have different scale from main
>> display.
> If Xinerama is disabled the method will return the primary screen size
> which is your favorite one.

But the popup should use the bounds from the screen where they will be 
shown, which is not necessary the main.

>>  - The toolkit method should be reworked.
> It as an open question at least for 9. I can file a bug if you want.

Toolkit bug is unrelated to this so its up to you. But the fix is quite 
easy.


-- 
Best regards, Sergey.

From semyon.sadetsky at oracle.com  Thu Sep 29 06:54:34 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 09:54:34 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
Message-ID: <d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>



On 9/28/2016 10:54 PM, Sergey Bylokhov wrote:
> On 23.09.16 21:39, Semyon Sadetsky wrote:
>>> Just check what value will be returned if the system have two displays
>>> and each will have own scale, the result will be downscaled based on
>>> default config.
>> Did you really try this? Because I did not see any Linux within the
>> supported ones that allows this. Would be nice if you could share info
>> how to get different scales for two monitors.
>
> It is not necessary to check, it is obvious from the code. It is 
> broken in this case.
But this behavior is unsupported. Why should I check it?
>
>>> We have two bugs:
>>>  - This bug is about menu related code, it should care about bounds of
>>> gc where these popup will be shown, it should not use the method which
>>> return the bounds of the primary screen. In current fix the location
>>> will be incorrect if Xinerama is disabled and menu will be shown on
>>> non-primary screen, if this screen have different scale from main
>>> display.
>> If Xinerama is disabled the method will return the primary screen size
>> which is your favorite one.
>
> But the popup should use the bounds from the screen where they will be 
> shown, which is not necessary the main.
Xinerama is always on in the supported OSes. And that is how it worked 
before the regression and there were no complains. It was not introduced 
in 9 while the regression is caused fix in 9. So, if you want I could 
create a separate issue to investigate why it was solved so, but it is 
unrelated to the fix. The fix simply eliminates the regression.
>
>>>  - The toolkit method should be reworked.
>> It as an open question at least for 9. I can file a bug if you want.
>
> Toolkit bug is unrelated to this so its up to you. But the fix is 
> quite easy.
>
>


From semyon.sadetsky at oracle.com  Thu Sep 29 06:55:17 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 09:55:17 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
Message-ID: <c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>

Looks good.

--Semyon


On 9/28/2016 8:16 PM, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the fix:
>   bug: https://bugs.openjdk.java.net/browse/JDK-8166591
>   webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02
>
>   This issue has been risen and investigated by JetBrains team in the 
> email:
> http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html
>
>   MacOS Sierra 10.12 sends many scroll events with values close to 
> zero when the trackpad is used. The small scroll values are rounded to 
> +1 or -1 so one line scroll would be possible. It leads that many 
> small scroll events causes fast scrolling.
>
>   The proposed fix accumulates scroll values from the trackpad until 
> they exceed some threshold  values. Only after that 
> MouseWheelEvent.wheelRotation value is set. Mouse wheel scroll events 
> are handled as before, small values are just rounded to + or -1.
>
>   Thanks,
>   Alexandr.


From Sergey.Bylokhov at oracle.com  Thu Sep 29 12:37:22 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 15:37:22 +0300
Subject: <AWT Dev> [9] Fix for JDK-8058950 : [TESTBUG] There is no F1
 dialog when the case loading, so we can't restore it.
In-Reply-To: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>
References: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>
Message-ID: <75762609-344b-21c1-32cd-7b96094c4fa9@oracle.com>

Should this test start on OSX? I think we can tweak the platforms via 
@req tag.

On 21.09.16 21:04, Ajit Ghaisas wrote:
> Hi,
>
> Bug :
>      https://bugs.openjdk.java.net/browse/JDK-8058950
>
> Issue :
>     Minimized test frame cannot be restored.
>
> Fix :
>    1. The test fix is quite simple - to introduce delay between frame.setVisible(true) and frame.setExtendedState(Frame.ICONIFIED).
>    2. I have modified test - not to use Applet. This results in multiple changes when file diff is seen.
>
> Webrev :
>    http://cr.openjdk.java.net/~aghaisas/8058950/webrev.00/
>
> Request you to review.
>
> Regards,
> Ajit
>


-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Sep 29 13:29:46 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 16:29:46 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
Message-ID: <CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>

The signature of the NSEvent constructor is changed.
It is called from AWTView.m (fixed) and CTrayIcon.m (!not fixed!)

Could you please support not only the phase start, but the phase end too?
It will be useful, when we decide to support precise scrolling in JScrollPane,
because we will be able to align precise wheel rotation to integer part.
So when an user stops scrolling we can align lines in a lists or trees.


>> Could you review the fix:
>>   bug: https://bugs.openjdk.java.net/browse/JDK-8166591
>>   webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02
>>
>>   This issue has been risen and investigated by JetBrains team in the
>> email:
>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html
>>
>>   MacOS Sierra 10.12 sends many scroll events with values close to zero
>> when the trackpad is used. The small scroll values are rounded to +1 or -1
>> so one line scroll would be possible. It leads that many small scroll events
>> causes fast scrolling.
>>
>>   The proposed fix accumulates scroll values from the trackpad until they
>> exceed some threshold  values. Only after that MouseWheelEvent.wheelRotation
>> value is set. Mouse wheel scroll events are handled as before, small values
>> are just rounded to + or -1.


-- 
Best regards,
Sergey A. Malenkov

From peter.brunet at oracle.com  Thu Sep 29 13:35:54 2016
From: peter.brunet at oracle.com (Pete Brunet)
Date: Thu, 29 Sep 2016 08:35:54 -0500
Subject: <AWT Dev> RfR JDK-8160893 [macosx] JMenuItems in JPopupMenu are
 not accessible
In-Reply-To: <a0a7ef8f-d5cb-4bde-e8da-bff1bd77924a@oracle.com>
References: <86a505c8-38fe-f01a-8125-7fb1b973cb81@oracle.com>
	<99535873-b42a-2b16-16c9-0aa23ca7ea25@oracle.com>
	<3c17f183-b869-b496-8679-2204429bde0f@jetbrains.com>
	<a0a7ef8f-d5cb-4bde-e8da-bff1bd77924a@oracle.com>
Message-ID: <0144990c-4025-ca44-fe72-b5c2e513e1bf@oracle.com>

Thanks, I will wait a bit before pushing in case awt-dev folks have any
input.  -Pete

On 9/28/16 12:22 PM, Alexander Scherbatiy wrote:
> The fix looks good to me.
>
> I have also added awt-dev alias because fix changes the native part.
>
> Thanks,
> Alexandr.
>
> On 26/09/16 16:22, Anton Tarasov wrote:
>> Hi Pete,
>>
>> The fix looks fine to me.
>>
>> Thanks,
>> Anton.
>>
>> On 9/24/2016 2:59 AM, Pete Brunet wrote:
>>> New webrev:
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.02/
>>>
>>> I added a null check at line 688 like the one at line 693.
>>>
>>> Pete
>>>
>>> On 9/23/16 2:46 PM, Pete Brunet wrote:
>>>> Please review the patch for JDK-8160893.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8160893
>>>> Patch: http://cr.openjdk.java.net/~ptbrunet/JDK-8160893/webrev.01/
>>>>
>>>> This patch adds support to post menu related events:
>>>> kAXMenuOpenedNotification, kAXMenuClosedNotification, and
>>>> kAXMenuItemSelectedNotification.  Also note that these changes had
>>>> impacts on the current combo box behavior so you'll see combo boxes
>>>> filtered out from this fix.  The combo box behavior is currently
>>>> broken
>>>> and will be fixed at a later date but at least for now I didn't want
>>>> this patch to change that (broken) behavior.
>>>>
>>>> TiA,
>>>> Pete
>>
>


From alexandr.scherbatiy at oracle.com  Thu Sep 29 14:58:16 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Thu, 29 Sep 2016 18:58:16 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
Message-ID: <817543bc-c791-eb43-3430-b27acd23f386@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev.03

- NSEvent constructor call is updated in the CTrayIcon.m
- The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll 
masks are added.

Thanks,
Alexandr.

On 29/09/16 17:29, Sergey Malenkov wrote:
> The signature of the NSEvent constructor is changed.
> It is called from AWTView.m (fixed) and CTrayIcon.m (!not fixed!)
>
> Could you please support not only the phase start, but the phase end too?
> It will be useful, when we decide to support precise scrolling in JScrollPane,
> because we will be able to align precise wheel rotation to integer part.
> So when an user stops scrolling we can align lines in a lists or trees.
>
>
>>> Could you review the fix:
>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8166591
>>>    webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02
>>>
>>>    This issue has been risen and investigated by JetBrains team in the
>>> email:
>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html
>>>
>>>    MacOS Sierra 10.12 sends many scroll events with values close to zero
>>> when the trackpad is used. The small scroll values are rounded to +1 or -1
>>> so one line scroll would be possible. It leads that many small scroll events
>>> causes fast scrolling.
>>>
>>>    The proposed fix accumulates scroll values from the trackpad until they
>>> exceed some threshold  values. Only after that MouseWheelEvent.wheelRotation
>>> value is set. Mouse wheel scroll events are handled as before, small values
>>> are just rounded to + or -1.
>


From semyon.sadetsky at oracle.com  Thu Sep 29 15:33:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 18:33:12 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8132664:
 closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on
 Windows
In-Reply-To: <16096f2e-ba45-31cf-c322-0668239e931d@oracle.com>
References: <55BF7A25.50301@oracle.com> <55BF8354.7060200@oracle.com>
	<55C0A7EF.80809@oracle.com>
	<16096f2e-ba45-31cf-c322-0668239e931d@oracle.com>
Message-ID: <eb7004ad-2916-1a12-c742-b76076e850e2@oracle.com>

On 9/27/2016 7:09 PM, Sergey Bylokhov wrote:

> On 04.08.15 14:54, Semyon Sadetsky wrote:
>> On 8/3/2015 6:05 PM, Sergey Bylokhov wrote:
>>> Hi, Semyon
>>> Did you try to change dwMilliseconds from INFINITE to the timeout(10
>>> seconds by default?) which is passed to the method? It does not help?
>>> Because even when dnd is not used we should not wait event for
>>> infinite time.
>> It would not help to fix the issue because 10 seconds is too big
>> interval. But for consistency it is not bad to have a time limit.
>> http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.01/
>
> Looks fine. Please file separate issue that syncNativeQueue() should 
> check that dnd callbacks are started/completed, because 
> "(newEventNumber - eventNumber) > 2" check is useless if we are in the 
> DND. And if some callbacks are in progress syncNativeQueue() should 
> notify the java side that we should call syncNativeQueue() one more time.
I have modified the fix to take the above into account. The updated 
webev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.02/
>
>>
>>>
>>> On 03.08.15 17:26, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please review fix for JDK9:
>>>>
>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8132664
>>>> webrev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.00/
>>>>
>>>> DoDragDrop() is blocking, so upon drag operation is triggered the
>>>> toolkit thread is blocked and the WM_AWT_WAIT cannot be processed
>>>> which in its turn blocks the AWT robot.
>>>> The solution is to escape AWT robot waiting in syncNativeQueue() if
>>>> drag operation is in progress.
>>>>
>>>> --Semyon
>>>
>>>
>>
>
>


From Alan.Burlison at oracle.com  Thu Sep 29 17:32:59 2016
From: Alan.Burlison at oracle.com (Alan Burlison)
Date: Thu, 29 Sep 2016 18:32:59 +0100
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
Message-ID: <6f6d69ff-27d6-9dfa-94ac-b7cdf7cc53dc@oracle.com>

On 27/09/2016 16:41, Alan Burlison wrote:

> Done, new webrev at http://cr.openjdk.java.net/~alanbur/JDK-8165232.v2/

Does this look OK?

-- 
Alan Burlison
--

From malenkov at gmail.com  Thu Sep 29 17:42:16 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 20:42:16 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
Message-ID: <CANTFZ2gk2A_kb_HecgWm0Hqm4F-pwfZjaaY7nBr_2d_03cegOA@mail.gmail.com>

It is OK for me. Thanks!
The fix is tested. The patch for 8u is attached.
It slightly differs because of changed codebase.

Could you please read comments about "deazone" in the following issue:
https://youtrack.jetbrains.com/issue/IDEA-158500
Is DELTA_THRESHOLD introduced to solve such a deadzone?


On Thu, Sep 29, 2016 at 5:58 PM, Alexander Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.03
>
> - NSEvent constructor call is updated in the CTrayIcon.m
> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll masks
> are added.
>
> Thanks,
> Alexandr.
>
>
> On 29/09/16 17:29, Sergey Malenkov wrote:
>>
>> The signature of the NSEvent constructor is changed.
>> It is called from AWTView.m (fixed) and CTrayIcon.m (!not fixed!)
>>
>> Could you please support not only the phase start, but the phase end too?
>> It will be useful, when we decide to support precise scrolling in
>> JScrollPane,
>> because we will be able to align precise wheel rotation to integer part.
>> So when an user stops scrolling we can align lines in a lists or trees.
>>
>>
>>>> Could you review the fix:
>>>>    bug: https://bugs.openjdk.java.net/browse/JDK-8166591
>>>>    webrev: http://cr.openjdk.java.net/~alexsch/8166591/webrev.02
>>>>
>>>>    This issue has been risen and investigated by JetBrains team in the
>>>> email:
>>>>
>>>> http://mail.openjdk.java.net/pipermail/awt-dev/2016-September/011991.html
>>>>
>>>>    MacOS Sierra 10.12 sends many scroll events with values close to zero
>>>> when the trackpad is used. The small scroll values are rounded to +1 or
>>>> -1
>>>> so one line scroll would be possible. It leads that many small scroll
>>>> events
>>>> causes fast scrolling.
>>>>
>>>>    The proposed fix accumulates scroll values from the trackpad until
>>>> they
>>>> exceed some threshold  values. Only after that
>>>> MouseWheelEvent.wheelRotation
>>>> value is set. Mouse wheel scroll events are handled as before, small
>>>> values
>>>> are just rounded to + or -1.
>>
>>
>



-- 
Best regards,
Sergey A. Malenkov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: IDEA_158500.patch
Type: application/octet-stream
Size: 12446 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160929/18ad207f/IDEA_158500.patch>

From malenkov at gmail.com  Thu Sep 29 17:52:29 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 20:52:29 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2gk2A_kb_HecgWm0Hqm4F-pwfZjaaY7nBr_2d_03cegOA@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2gk2A_kb_HecgWm0Hqm4F-pwfZjaaY7nBr_2d_03cegOA@mail.gmail.com>
Message-ID: <CANTFZ2ihkD=pT+wWjR3JjHY6PstU15MOUiopEBYK1L0nGgK2PQ@mail.gmail.com>

> Could you please read comments about "deazone" in the following issue:
> https://youtrack.jetbrains.com/issue/IDEA-158500
> Is DELTA_THRESHOLD introduced to solve such a deadzone?

If your scroll gesture on a trackpad is very slow,
a list will be scrolled by a single line after unexpected delay:

(52,234),wheelRotation=0,preciseWheelRotation=0.0222015380859375
(52,234),wheelRotation=0,preciseWheelRotation=0.0234222412109375
(52,234),wheelRotation=0,preciseWheelRotation=0.0239715576171875
(52,234),wheelRotation=0,preciseWheelRotation=0.0242919921875
(52,234),wheelRotation=0,preciseWheelRotation=0.02447509765625
(52,234),wheelRotation=0,preciseWheelRotation=0.024566650390625
(52,234),wheelRotation=0,preciseWheelRotation=0.0246429443359375
(52,234),wheelRotation=0,preciseWheelRotation=0.0244903564453125
(52,234),wheelRotation=0,preciseWheelRotation=0.0444183349609375
(52,234),wheelRotation=0,preciseWheelRotation=0.023895263671875
(52,234),wheelRotation=0,preciseWheelRotation=0.0244903564453125
(52,234),wheelRotation=0,preciseWheelRotation=0.0247344970703125
(52,234),wheelRotation=0,preciseWheelRotation=0.0248260498046875
(52,234),wheelRotation=0,preciseWheelRotation=0.0248260498046875
(52,234),wheelRotation=0,preciseWheelRotation=0.024505615234375
(52,234),wheelRotation=0,preciseWheelRotation=0.0222015380859375
(52,234),wheelRotation=0,preciseWheelRotation=0.0233306884765625
(52,234),wheelRotation=0,preciseWheelRotation=0.0238494873046875
(52,234),wheelRotation=0,preciseWheelRotation=0.0241241455078125
(52,234),wheelRotation=0,preciseWheelRotation=0.0222015380859375
(52,234),wheelRotation=0,preciseWheelRotation=0.023162841796875
(52,234),wheelRotation=0,preciseWheelRotation=0.023712158203125
(52,234),wheelRotation=0,preciseWheelRotation=0.024017333984375
(52,234),wheelRotation=0,preciseWheelRotation=0.0242156982421875
(52,234),wheelRotation=0,preciseWheelRotation=0.0243377685546875
(52,234),wheelRotation=0,preciseWheelRotation=0.02447509765625
(52,234),wheelRotation=0,preciseWheelRotation=0.0245513916015625
(52,234),wheelRotation=0,preciseWheelRotation=0.0250701904296875
(52,234),wheelRotation=0,preciseWheelRotation=0.0251312255859375
(52,234),wheelRotation=0,preciseWheelRotation=0.0251617431640625
(52,234),wheelRotation=0,preciseWheelRotation=0.0251617431640625
(52,234),wheelRotation=0,preciseWheelRotation=0.0251922607421875
(52,234),wheelRotation=1,preciseWheelRotation=0.0252227783203125

-- 
Best regards,
Sergey A. Malenkov

From semyon.sadetsky at oracle.com  Thu Sep 29 18:11:29 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 21:11:29 +0300
Subject: <AWT Dev> [9] Review request for 8153526: [Unity]
 Taskbar.getTaskbar().setMenu(null) doesn't remove menu
In-Reply-To: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
References: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
Message-ID: <dd855cd2-5e4a-ab10-d831-f03780d0657a@oracle.com>

Hi Alexander,

The fix looks good.

I guess the second callback parameter was added by mistake initially.

Also I noticed after menu items added/removed  a number of times GTK 
prints messages:

(java:20921): GLib-CRITICAL **: g_hash_table_insert_internal: assertion 
'hash_table != NULL' failed

(java:20921): GLib-GObject-WARNING **: invalid unclassed pointer in cast 
to 'DbusmenuServer'

(java:20921): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_foreach: 
assertion 'DBUSMENU_IS_MENUITEM(mi)' failed

and sometimes the process even cashes in libdbusmenu-glib.so.

Probably we need some protection from that.

--Semyon


On 06.09.2016 20:56, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8153526/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8153526
>
>
>


From Sergey.Bylokhov at oracle.com  Thu Sep 29 18:22:07 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 21:22:07 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<89f43004-f933-e609-b904-6b83dea722c6@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
Message-ID: <38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>

On 29.09.16 9:54, Semyon Sadetsky wrote:
>>>> We have two bugs:
>>>>  - This bug is about menu related code, it should care about bounds of
>>>> gc where these popup will be shown, it should not use the method which
>>>> return the bounds of the primary screen. In current fix the location
>>>> will be incorrect if Xinerama is disabled and menu will be shown on
>>>> non-primary screen, if this screen have different scale from main
>>>> display.
>>> If Xinerama is disabled the method will return the primary screen size
>>> which is your favorite one.
>>
>> But the popup should use the bounds from the screen where they will be
>> shown, which is not necessary the main.
> Xinerama is always on in the supported OSes. And that is how it worked
> before the regression and there were no complains. It was not introduced
> in 9 while the regression is caused fix in 9. So, if you want I could
> create a separate issue to investigate why it was solved so, but it is
> unrelated to the fix. The fix simply eliminates the regression.

This is a part of HiDPI support. The popup code should use the bounds of 
the screen where it is located. It should not depend from the method which:
  - Support data for the main screen only.
  - Even for this screen it returns incorrect data.

-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Sep 29 18:30:22 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 21:30:22 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
Message-ID: <CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>

> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll masks
> are added.

Could you please use these masks in your fix?
Look at the following scenario:
- Perform slow and short scroll gesture
- Accumulator is less than threshold
- All wheel events during this gesture has wheelRotation=0
- Nothing is scrolled actually.
- Repeat several such gestures - nothing is scrolled

So I suggest to process the phase end to align accumulated value.
It adds an ability to scroll with short scroll gesture.
If you align accumulated value to bigger integer,
it also aligns scrolled lines automatically
when we support per-pixel scrolling.

-- 
Best regards,
Sergey A. Malenkov

From semyon.sadetsky at oracle.com  Thu Sep 29 18:35:10 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 21:35:10 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<2cf62bc8-4845-3f1d-85f7-0176b2f9849f@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
Message-ID: <29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>



On 29.09.2016 21:22, Sergey Bylokhov wrote:
> On 29.09.16 9:54, Semyon Sadetsky wrote:
>>>>> We have two bugs:
>>>>>  - This bug is about menu related code, it should care about 
>>>>> bounds of
>>>>> gc where these popup will be shown, it should not use the method 
>>>>> which
>>>>> return the bounds of the primary screen. In current fix the location
>>>>> will be incorrect if Xinerama is disabled and menu will be shown on
>>>>> non-primary screen, if this screen have different scale from main
>>>>> display.
>>>> If Xinerama is disabled the method will return the primary screen size
>>>> which is your favorite one.
>>>
>>> But the popup should use the bounds from the screen where they will be
>>> shown, which is not necessary the main.
>> Xinerama is always on in the supported OSes. And that is how it worked
>> before the regression and there were no complains. It was not introduced
>> in 9 while the regression is caused fix in 9. So, if you want I could
>> create a separate issue to investigate why it was solved so, but it is
>> unrelated to the fix. The fix simply eliminates the regression.
>
> This is a part of HiDPI support. The popup code should use the bounds 
> of the screen where it is located. It should not depend from the 
> method which:
>  - Support data for the main screen only.
>  - Even for this screen it returns incorrect data.
I did not get that.
The fix restores the the previous way to get screen bounds, which was 
not introduced as a part of HiDPI but much earier. It had been working 
before 8137571 without complains (no bugs reported).

Or did you mean it won't work in HiDPI? I tested, it works for both 
HiDPI and non-HiDPI displays while the current code doesn't work for both.

From Sergey.Bylokhov at oracle.com  Thu Sep 29 18:49:37 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 21:49:37 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
Message-ID: <6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>

On 29.09.16 21:30, Sergey Malenkov wrote:
>> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll masks
>> are added.
>
> Could you please use these masks in your fix?
> Look at the following scenario:
> - Perform slow and short scroll gesture
> - Accumulator is less than threshold
> - All wheel events during this gesture has wheelRotation=0
> - Nothing is scrolled actually.
> - Repeat several such gestures - nothing is scrolled

Just to clarify, if you perform slow scroll gesture and the accumulator 
will be less than threshold means that you should not scroll, no? 
Because the sum of overall scroll events are less than one line. The 
fact that you need to "move a certain minimum distance before the scroll 
takes effect" is OSX bug, I wonder how the native app works, do they 
have the same "deadzone"?

> So I suggest to process the phase end to align accumulated value.
> It adds an ability to scroll with short scroll gesture.
> If you align accumulated value to bigger integer,
> it also aligns scrolled lines automatically
> when we support per-pixel scrolling.

Per pixel scrolling should depend from the preciseWheelRotation, 
otherwise on the retina display you will be able to scroll only by the 
units(2 pixels).

-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 29 18:55:39 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 21:55:39 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<f2f1bf4c-15df-1bdc-521a-219981af2313@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
Message-ID: <f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>

On 29.09.16 21:35, Semyon Sadetsky wrote:
>> This is a part of HiDPI support. The popup code should use the bounds
>> of the screen where it is located. It should not depend from the
>> method which:
>>  - Support data for the main screen only.
>>  - Even for this screen it returns incorrect data.
> I did not get that.
> The fix restores the the previous way to get screen bounds, which was
> not introduced as a part of HiDPI but much earier. It had been working
> before 8137571 without complains (no bugs reported).

The previous way "to get screen bounds" is incorrect, and we will get 
the same bug when toolkit method will be changed.

> Or did you mean it won't work in HiDPI? I tested, it works for both
> HiDPI and non-HiDPI displays while the current code doesn't work for both.


-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Sep 29 18:56:35 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 21:56:35 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
Message-ID: <CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>

> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll masks
> are added.

Now we use the scrollMask value and the following constants:

static final int SCROLL_MASK_WHEEL = 1;
static final int SCROLL_MASK_TRACKPAD = 1 << 1;
static final int SCROLL_MASK_PHASE_BEGAN = 1 << 2;
static final int SCROLL_MASK_PHASE_CANCELLED = 1 << 3;
static final int SCROLL_MASK_PHASE_ENDED = 1 << 4;

All these masks cannot be used together.
So I suggest to replace it with the scrollPhase value:

static final int SCROLL_PHASE_UNSUPPORTED = 0; // for mouse events
static final int SCROLL_PHASE_BEGAN = 1;
static final int SCROLL_PHASE_CONTINUED = 2;
static final int SCROLL_PHASE_CANCELLED = 3;
static final int SCROLL_PHASE_ENDED = 4;

It simplifies if-statements:
- if ((scrollMask & NSEvent.SCROLL_MASK_PHASE_BEGAN) != 0) {
+ if (scrollPhase == NSEvent.SCROLL_PHASE_BEGAN) {

and the following method:

+ (jint) scrollTypeToMask: (NSEventPhase) phase {
    if (phase) return SCROLL_PHASE_UNSUPPORTED;
    switch (phase) {
        case NSEventPhaseBegan:    return SCROLL_MASK_PHASE_BEGAN;
        case NSEventPhaseCancelled:    return SCROLL_MASK_PHASE_CANCELLED;
        case NSEventPhaseEnded:    return SCROLL_MASK_PHASE_ENDED;
    }
    return SCROLL_PHASE_CONTINUED;
}

What do you think?

-- 
Best regards,
Sergey A. Malenkov

From malenkov at gmail.com  Thu Sep 29 19:08:40 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 22:08:40 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
	<6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
Message-ID: <CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>

>> Look at the following scenario:
>> - Perform slow and short scroll gesture
>> - Accumulator is less than threshold
>> - All wheel events during this gesture has wheelRotation=0
>> - Nothing is scrolled actually.
>> - Repeat several such gestures - nothing is scrolled
>
> Just to clarify, if you perform slow scroll gesture and the accumulator will
> be less than threshold means that you should not scroll, no? Because the sum
> of overall scroll events are less than one line. The fact that you need to
> "move a certain minimum distance before the scroll takes effect" is OSX bug,
> I wonder how the native app works, do they have the same "deadzone"?

Native apps support per-pixel scrolling, so their "deadzone" is 10 times less.

>> So I suggest to process the phase end to align accumulated value.
>> It adds an ability to scroll with short scroll gesture.
>> If you align accumulated value to bigger integer,
>> it also aligns scrolled lines automatically
>> when we support per-pixel scrolling.
>
> Per pixel scrolling should depend from the preciseWheelRotation, otherwise
> on the retina display you will be able to scroll only by the units(2
> pixels).

In Java lists and trees a unit is a line (~12 or ~24 pixels)

-- 
Best regards,
Sergey A. Malenkov

From semyon.sadetsky at oracle.com  Thu Sep 29 19:14:02 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 22:14:02 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<1a80a68b-d104-baa2-aa06-01d68807076d@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
Message-ID: <a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>



On 29.09.2016 21:55, Sergey Bylokhov wrote:
> On 29.09.16 21:35, Semyon Sadetsky wrote:
>>> This is a part of HiDPI support. The popup code should use the bounds
>>> of the screen where it is located. It should not depend from the
>>> method which:
>>>  - Support data for the main screen only.
>>>  - Even for this screen it returns incorrect data.
>> I did not get that.
>> The fix restores the the previous way to get screen bounds, which was
>> not introduced as a part of HiDPI but much earier. It had been working
>> before 8137571 without complains (no bugs reported).
>
> The previous way "to get screen bounds" is incorrect, and we will get 
> the same bug when toolkit method will be changed.
May be it is incorrect but it is working. It is better than correct and 
not working. It seems we have returned to the beginning of the 
discussion. I suggest to file a new bug to investigate "the correctness" 
and the necessity to fix it 9. But the current fix is must for 9.
>
>> Or did you mean it won't work in HiDPI? I tested, it works for both
>> HiDPI and non-HiDPI displays while the current code doesn't work for 
>> both.
>
>


From Sergey.Bylokhov at oracle.com  Thu Sep 29 19:18:59 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 22:18:59 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
	<6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
	<CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>
Message-ID: <5044841c-d2d3-131e-d33c-b1157bc293c1@oracle.com>

On 29.09.16 22:08, Sergey Malenkov wrote:
>> Just to clarify, if you perform slow scroll gesture and the accumulator will
>> be less than threshold means that you should not scroll, no? Because the sum
>> of overall scroll events are less than one line. The fact that you need to
>> "move a certain minimum distance before the scroll takes effect" is OSX bug,
>> I wonder how the native app works, do they have the same "deadzone"?
>
> Native apps support per-pixel scrolling, so their "deadzone" is 10 times less.

It depends from the application, just checked on the list of emails in 
the Thunderbird which have small "deadzone". I think we should not do 
any magic in this files. only get native event and post it to upper 
level(the int value should be accumulated) And this is responsibility of 
upper level to do some work depending from the MouseWheelEvent.

>
>>> So I suggest to process the phase end to align accumulated value.
>>> It adds an ability to scroll with short scroll gesture.
>>> If you align accumulated value to bigger integer,
>>> it also aligns scrolled lines automatically
>>> when we support per-pixel scrolling.
>>
>> Per pixel scrolling should depend from the preciseWheelRotation, otherwise
>> on the retina display you will be able to scroll only by the units(2
>> pixels).
>
> In Java lists and trees a unit is a line (~12 or ~24 pixels)

This how these component implemented and I think we can change or tweak 
this. If you run SwingSet2 demo on "Scroll Pane Demo" you will see that 
it is possible to scroll per units(every pixel on non-retina/every two 
pixels on the retina).


-- 
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Thu Sep 29 19:35:28 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 22:35:28 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<4caf874d-fada-26df-03ac-2e990c0dac9a@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
Message-ID: <8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>

On 29.09.16 22:14, Semyon Sadetsky wrote:
>> The previous way "to get screen bounds" is incorrect, and we will get
>> the same bug when toolkit method will be changed.
> May be it is incorrect but it is working. It is better than correct and
> not working. It seems we have returned to the beginning of the
> discussion. I suggest to file a new bug to investigate "the correctness"
> and the necessity to fix it 9. But the current fix is must for 9.

The usage of toolkit method here is incorrect, adding it again in this 
patch is also incorrect. The usage of GC which you remove is correct and 
should be preserved.
The problem that the popups do not work is in the way how bounds are 
used. And this should be fixed.

-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Sep 29 19:40:19 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 22:40:19 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <5044841c-d2d3-131e-d33c-b1157bc293c1@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
	<6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
	<CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>
	<5044841c-d2d3-131e-d33c-b1157bc293c1@oracle.com>
Message-ID: <CANTFZ2hTGp+pgFteH6=4=hTdYt4yG+CD_9SNCGaj04i+0xVKVw@mail.gmail.com>

> It depends from the application, just checked on the list of emails in the
> Thunderbird which have small "deadzone". I think we should not do any magic
> in this files. only get native event and post it to upper level(the int
> value should be accumulated) And this is responsibility of upper level to do
> some work depending from the MouseWheelEvent.

But we already did some magic to support mouse event.
On the top level I have no access to the phase values.


>> In Java lists and trees a unit is a line (~12 or ~24 pixels)
>
> This how these component implemented and I think we can change or tweak
> this. If you run SwingSet2 demo on "Scroll Pane Demo" you will see that it
> is possible to scroll per units(every pixel on non-retina/every two pixels
> on the retina).

This is not a list. And this image scrolls very-very slow.
Usually we setUnitIncrement(10) to such components.
Note, that MouseWheelEvent contains deltaY (line scroll)
instead of scrollingDeltaY (pixel scroll) from native events.

-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Thu Sep 29 20:00:07 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 29 Sep 2016 23:00:07 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2hTGp+pgFteH6=4=hTdYt4yG+CD_9SNCGaj04i+0xVKVw@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
	<6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
	<CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>
	<5044841c-d2d3-131e-d33c-b1157bc293c1@oracle.com>
	<CANTFZ2hTGp+pgFteH6=4=hTdYt4yG+CD_9SNCGaj04i+0xVKVw@mail.gmail.com>
Message-ID: <43d535eb-76a9-fb6b-b407-127c8de7a548@oracle.com>

>> value should be accumulated) And this is responsibility of upper level to do
>> some work depending from the MouseWheelEvent.
>
> But we already did some magic to support mouse event.
> On the top level I have no access to the phase values.

But how this values helps you? If we roundup the accumulator on the "end 
phase" the scroll will be slow in the middle phase, no?

>
>
>> This how these component implemented and I think we can change or tweak
>> this. If you run SwingSet2 demo on "Scroll Pane Demo" you will see that it
>> is possible to scroll per units(every pixel on non-retina/every two pixels
>> on the retina).
>
> This is not a list. And this image scrolls very-very slow.
> Usually we setUnitIncrement(10) to such components.

It is scrolled slow-slow because we get such notifications from native. 
I am still hope Apple will fix this.

> Note, that MouseWheelEvent contains deltaY (line scroll)
> instead of scrollingDeltaY (pixel scroll) from native events.

That's a good question can we use scrollingDeltaX/Y instead and in the 
same time tweak the "scrollAmount" value. What is a "scrollAmount" means 
here? is it a pixels? If yes why we cannot post scrollingDeltaX/Y as a 
scrollAmount(and set wheelRotation as +-1)?


-- 
Best regards, Sergey.

From malenkov at gmail.com  Thu Sep 29 20:17:41 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Thu, 29 Sep 2016 23:17:41 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <43d535eb-76a9-fb6b-b407-127c8de7a548@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2iauBRY2TndCcLBgi0jRbYroJVsQr2r2-cHdNrjfF5rFA@mail.gmail.com>
	<6d72ece6-c5ca-95e0-f94e-2e3f8259fd3b@oracle.com>
	<CANTFZ2j0a051XaV02yJBauhRs_Te=zGf8Gyc5nrKg5EhM3-=_w@mail.gmail.com>
	<5044841c-d2d3-131e-d33c-b1157bc293c1@oracle.com>
	<CANTFZ2hTGp+pgFteH6=4=hTdYt4yG+CD_9SNCGaj04i+0xVKVw@mail.gmail.com>
	<43d535eb-76a9-fb6b-b407-127c8de7a548@oracle.com>
Message-ID: <CANTFZ2giOo3P9o_DDso-Xr445y+zLi3+sAu57Un5KUufMeTBPg@mail.gmail.com>

>> But we already did some magic to support mouse event.
>> On the top level I have no access to the phase values.
>
> But how this values helps you? If we roundup the accumulator on the "end
> phase" the scroll will be slow in the middle phase, no?

I want to support short gestures like we supported mouse wheel.
When you accumulated 0.4 and ended a phase, the value should be 1.
Possibly, we have to use here a threshold ~0.1


>> This is not a list. And this image scrolls very-very slow.
>> Usually we setUnitIncrement(10) to such components.
>
> It is scrolled slow-slow because we get such notifications from native. I am
> still hope Apple will fix this.

Nope. Windows provides the same values and we have a very slow scrolling here.

>> Note, that MouseWheelEvent contains deltaY (line scroll)
>> instead of scrollingDeltaY (pixel scroll) from native events.
>
> That's a good question can we use scrollingDeltaX/Y instead and in the same
> time tweak the "scrollAmount" value. What is a "scrollAmount" means here? is
> it a pixels? If yes why we cannot post scrollingDeltaX/Y as a
> scrollAmount(and set wheelRotation as +-1)?

It is a units in Swing.  See MouseWheelEvent.getUnitsToScroll()
For lists and trees it is amount of lines to scroll per mouse wheel tick.

-- 
Best regards,
Sergey A. Malenkov

From semyon.sadetsky at oracle.com  Thu Sep 29 20:40:12 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 29 Sep 2016 23:40:12 +0300
Subject: <AWT Dev> [9] Review request for 8163101: dual-screen issue
 with JMenu, JPopupMenu
In-Reply-To: <8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
References: <08422cfa-7fe7-cf19-36fd-b707abbe4adf@oracle.com>
	<4b12af8f-d16e-d518-f1b8-e24175c3ca92@oracle.com>
	<68880a94-2d64-a4ee-c93b-ac13c83e5a34@oracle.com>
	<98b0d27f-513a-19d2-800e-9b11bd20a751@oracle.com>
	<c4437474-41a6-634b-447f-554af8c20656@oracle.com>
	<89e3807b-a33b-33e0-532d-5a8b6683ab32@oracle.com>
	<7e2cc9c7-f993-29e1-6b2c-f2a9a43e60eb@oracle.com>
	<813d5dfc-a83e-ab0d-67e8-efe5f8e3a379@oracle.com>
	<19007d0e-6007-116f-0257-5db26a49450b@oracle.com>
	<ceafb52e-c788-71f5-7945-356dab19160e@oracle.com>
	<04f7e574-8c85-c787-f08d-e6040ef098b8@oracle.com>
	<911c35c5-6627-60a6-c52a-a467b80e3097@oracle.com>
	<07ce3934-96fb-dc64-99df-995e5a0ca28a@oracle.com>
	<d88f1d0b-d467-324b-6237-84eeec50046e@oracle.com>
	<38787b3b-1356-977f-ca23-c6e728d3ceda@oracle.com>
	<29f01520-99b0-7438-02a5-51cc248be29d@oracle.com>
	<f45beddd-f4be-ac91-aeee-34786853021f@oracle.com>
	<a43d3eba-5d13-48de-0f83-2efa664da2a3@oracle.com>
	<8c7239fe-51c8-c8f4-84b2-87e16295761d@oracle.com>
Message-ID: <f4a857cc-ebd4-8c65-fd3c-ff9adf4389f3@oracle.com>

On 29.09.2016 22:35, Sergey Bylokhov wrote:

> On 29.09.16 22:14, Semyon Sadetsky wrote:
>>> The previous way "to get screen bounds" is incorrect, and we will get
>>> the same bug when toolkit method will be changed.
>> May be it is incorrect but it is working. It is better than correct and
>> not working. It seems we have returned to the beginning of the
>> discussion. I suggest to file a new bug to investigate "the correctness"
>> and the necessity to fix it 9. But the current fix is must for 9.
>
> The usage of toolkit method here is incorrect, adding it again in this 
> patch is also incorrect. The usage of GC which you remove is correct 
> and should be preserved.
I don't understand what you call correct and what incorrect. But "the 
usage of GC" results in unexpected behavior which may be only considered 
as incorrect by the user.
> The problem that the popups do not work is in the way how bounds are 
> used. And this should be fixed.
"in the way how bounds are used"  what does it mean?

From alexandr.scherbatiy at oracle.com  Thu Sep 29 21:30:53 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 01:30:53 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
Message-ID: <8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev.04

The fix uses the proposed changes below and sets a wheel rotation to +1 
or -1 when the scroll phase is ended and the accumulates delta value is 
small than the threshold.

Thanks,
Alexandr.

On 29/09/16 22:56, Sergey Malenkov wrote:
>> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll masks
>> are added.
> Now we use the scrollMask value and the following constants:
>
> static final int SCROLL_MASK_WHEEL = 1;
> static final int SCROLL_MASK_TRACKPAD = 1 << 1;
> static final int SCROLL_MASK_PHASE_BEGAN = 1 << 2;
> static final int SCROLL_MASK_PHASE_CANCELLED = 1 << 3;
> static final int SCROLL_MASK_PHASE_ENDED = 1 << 4;
>
> All these masks cannot be used together.
> So I suggest to replace it with the scrollPhase value:
>
> static final int SCROLL_PHASE_UNSUPPORTED = 0; // for mouse events
> static final int SCROLL_PHASE_BEGAN = 1;
> static final int SCROLL_PHASE_CONTINUED = 2;
> static final int SCROLL_PHASE_CANCELLED = 3;
> static final int SCROLL_PHASE_ENDED = 4;
>
> It simplifies if-statements:
> - if ((scrollMask & NSEvent.SCROLL_MASK_PHASE_BEGAN) != 0) {
> + if (scrollPhase == NSEvent.SCROLL_PHASE_BEGAN) {
>
> and the following method:
>
> + (jint) scrollTypeToMask: (NSEventPhase) phase {
>      if (phase) return SCROLL_PHASE_UNSUPPORTED;
>      switch (phase) {
>          case NSEventPhaseBegan:    return SCROLL_MASK_PHASE_BEGAN;
>          case NSEventPhaseCancelled:    return SCROLL_MASK_PHASE_CANCELLED;
>          case NSEventPhaseEnded:    return SCROLL_MASK_PHASE_ENDED;
>      }
>      return SCROLL_PHASE_CONTINUED;
> }
>
> What do you think?
>


From semyon.sadetsky at oracle.com  Thu Sep 29 21:44:15 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 30 Sep 2016 00:44:15 +0300
Subject: <AWT Dev> [9] Review request for 8153526: [Unity]
 Taskbar.getTaskbar().setMenu(null) doesn't remove menu
In-Reply-To: <dd855cd2-5e4a-ab10-d831-f03780d0657a@oracle.com>
References: <15d62d42-57b1-bb48-8f73-70af1828caef@oracle.com>
	<dd855cd2-5e4a-ab10-d831-f03780d0657a@oracle.com>
Message-ID: <ded68271-735b-bec7-dfa5-e5d54f4567ff@oracle.com>

Alexander, please ignore my comment about glib error messages. I cannot 
reproduce them anymore. It seems I got them before your fix.

--Semyon

On 29.09.2016 21:11, Semyon Sadetsky wrote:
> Hi Alexander,
>
> The fix looks good.
>
> I guess the second callback parameter was added by mistake initially.
>
> Also I noticed after menu items added/removed  a number of times GTK 
> prints messages:
>
> (java:20921): GLib-CRITICAL **: g_hash_table_insert_internal: 
> assertion 'hash_table != NULL' failed
>
> (java:20921): GLib-GObject-WARNING **: invalid unclassed pointer in 
> cast to 'DbusmenuServer'
>
> (java:20921): LIBDBUSMENU-GLIB-CRITICAL **: dbusmenu_menuitem_foreach: 
> assertion 'DBUSMENU_IS_MENUITEM(mi)' failed
>
> and sometimes the process even cashes in libdbusmenu-glib.so.
>
> Probably we need some protection from that.
>
> --Semyon
>
>
> On 06.09.2016 20:56, Alexander Zvegintsev wrote:
>> Hello,
>>
>> please review the fix
>>
>> http://cr.openjdk.java.net/~azvegint/jdk/9/8153526/00/
>>
>> for the issue
>>
>> https://bugs.openjdk.java.net/browse/JDK-8153526
>>
>>
>>
>


From malenkov at gmail.com  Fri Sep 30 09:59:36 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 12:59:36 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
Message-ID: <CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>

# C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d

The app is crashed as soon as I start scrolling. Investigating...
May be it is my fault during backporting.



LWCToolkit.m:
+// SCROLL EVENT MASK
+#define SCROLL_PHASE_UNSUPPORTED 1
...

replace the comment with the following one:

+// TRACKPAD SCROLL EVENT PHASE

On Fri, Sep 30, 2016 at 12:30 AM, Alexander Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.04
>
> The fix uses the proposed changes below and sets a wheel rotation to +1 or
> -1 when the scroll phase is ended and the accumulates delta value is small
> than the threshold.
>
> Thanks,
> Alexandr.
>
>
> On 29/09/16 22:56, Sergey Malenkov wrote:
>>>
>>> - The SCROLL_MASK_PHASE_CANCELLED  and SCROLL_MASK_PHASE_ENDED scroll
>>> masks
>>> are added.
>>
>> Now we use the scrollMask value and the following constants:
>>
>> static final int SCROLL_MASK_WHEEL = 1;
>> static final int SCROLL_MASK_TRACKPAD = 1 << 1;
>> static final int SCROLL_MASK_PHASE_BEGAN = 1 << 2;
>> static final int SCROLL_MASK_PHASE_CANCELLED = 1 << 3;
>> static final int SCROLL_MASK_PHASE_ENDED = 1 << 4;
>>
>> All these masks cannot be used together.
>> So I suggest to replace it with the scrollPhase value:
>>
>> static final int SCROLL_PHASE_UNSUPPORTED = 0; // for mouse events
>> static final int SCROLL_PHASE_BEGAN = 1;
>> static final int SCROLL_PHASE_CONTINUED = 2;
>> static final int SCROLL_PHASE_CANCELLED = 3;
>> static final int SCROLL_PHASE_ENDED = 4;
>>
>> It simplifies if-statements:
>> - if ((scrollMask & NSEvent.SCROLL_MASK_PHASE_BEGAN) != 0) {
>> + if (scrollPhase == NSEvent.SCROLL_PHASE_BEGAN) {
>>
>> and the following method:
>>
>> + (jint) scrollTypeToMask: (NSEventPhase) phase {
>>      if (phase) return SCROLL_PHASE_UNSUPPORTED;
>>      switch (phase) {
>>          case NSEventPhaseBegan:    return SCROLL_MASK_PHASE_BEGAN;
>>          case NSEventPhaseCancelled:    return
>> SCROLL_MASK_PHASE_CANCELLED;
>>          case NSEventPhaseEnded:    return SCROLL_MASK_PHASE_ENDED;
>>      }
>>      return SCROLL_PHASE_CONTINUED;
>> }
>>
>> What do you think?
>>
>



-- 
Best regards,
Sergey A. Malenkov

From malenkov at gmail.com  Fri Sep 30 10:31:21 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 13:31:21 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
Message-ID: <CANTFZ2gU_J2x77YQck6t4jD=T+cHYK4DotHe2NV97BWOm4d-Rg@mail.gmail.com>

> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>
> The app is crashed as soon as I start scrolling. Investigating...
> May be it is my fault during backporting.

Sorry, it was my fault. Now it works.

Consider how it works for one short gesture:

phase3 0 ~ 0.0 // unexpected PHASE_CONTINUED
phase2 0 ~ -0.0222015380859375 // PHASE_STARTED
phase3 0 ~ -0.1589202880859375
phase3 0 ~ -0.179595947265625
phase5 -1 ~ 0.0 // PHASE ENDED
phase1 -1 ~ -0.335968017578125
phase1 -1 ~ -0.3228607177734375
phase1 -1 ~ -0.338653564453125
phase1 -1 ~ -0.3087005615234375
phase1 -1 ~ -0.314056396484375
phase1 -1 ~ -0.314666748046875
phase1 -1 ~ -0.31573486328125
phase1 -1 ~ -0.2690277099609375
phase1 -1 ~ -0.2614288330078125
phase1 -1 ~ -0.211517333984375
phase1 -1 ~ -0.2041168212890625
phase1 -1 ~ -0.15740966796875
phase1 -1 ~ -0.1521148681640625
phase1 -1 ~ -0.1095123291015625
phase1 -1 ~ -0.1052703857421875
phase1 -1 ~ -0.067291259765625
phase1 -1 ~ -0.0644683837890625
phase1 -1 ~ -0.062286376953125
phase1 -1 ~ -0.060150146484375
phase1 -1 ~ -0.02899169921875
phase1 -1 ~ -0.0279083251953125
phase1 -1 ~ -0.0271148681640625
phase1 -1 ~ -0.026397705078125
phase1 -1 ~ -0.025970458984375
phase1 0 ~ 0.0

After short scroll a trackpad behaves as a mouse.
It is not good, because native list slows scrolling,
but Swing list scrolls a lot of lines...

-- 
Best regards,
Sergey A. Malenkov

From alexandr.scherbatiy at oracle.com  Fri Sep 30 10:48:02 2016
From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy)
Date: Fri, 30 Sep 2016 13:48:02 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2gU_J2x77YQck6t4jD=T+cHYK4DotHe2NV97BWOm4d-Rg@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2gU_J2x77YQck6t4jD=T+cHYK4DotHe2NV97BWOm4d-Rg@mail.gmail.com>
Message-ID: <cf6f2a8a-e511-6e0d-70b6-e614e66f02d8@oracle.com>



On 9/30/2016 1:31 PM, Sergey Malenkov wrote:
>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>
>> The app is crashed as soon as I start scrolling. Investigating...
>> May be it is my fault during backporting.
> Sorry, it was my fault. Now it works.
>
> Consider how it works for one short gesture:
>
> phase3 0 ~ 0.0 // unexpected PHASE_CONTINUED
> phase2 0 ~ -0.0222015380859375 // PHASE_STARTED
> phase3 0 ~ -0.1589202880859375
> phase3 0 ~ -0.179595947265625
> phase5 -1 ~ 0.0 // PHASE ENDED
> phase1 -1 ~ -0.335968017578125
> phase1 -1 ~ -0.3228607177734375
   This is because the trackpad sets NSScrollWheel phase value to null 
and we detect it is a mouse.
   Probably there is a better way to separate mouse wheel and trackpad 
events.

   Thanks,
   Alexandr.

> phase1 -1 ~ -0.338653564453125
> phase1 -1 ~ -0.3087005615234375
> phase1 -1 ~ -0.314056396484375
> phase1 -1 ~ -0.314666748046875
> phase1 -1 ~ -0.31573486328125
> phase1 -1 ~ -0.2690277099609375
> phase1 -1 ~ -0.2614288330078125
> phase1 -1 ~ -0.211517333984375
> phase1 -1 ~ -0.2041168212890625
> phase1 -1 ~ -0.15740966796875
> phase1 -1 ~ -0.1521148681640625
> phase1 -1 ~ -0.1095123291015625
> phase1 -1 ~ -0.1052703857421875
> phase1 -1 ~ -0.067291259765625
> phase1 -1 ~ -0.0644683837890625
> phase1 -1 ~ -0.062286376953125
> phase1 -1 ~ -0.060150146484375
> phase1 -1 ~ -0.02899169921875
> phase1 -1 ~ -0.0279083251953125
> phase1 -1 ~ -0.0271148681640625
> phase1 -1 ~ -0.026397705078125
> phase1 -1 ~ -0.025970458984375
> phase1 0 ~ 0.0
>
> After short scroll a trackpad behaves as a mouse.
> It is not good, because native list slows scrolling,
> but Swing list scrolls a lot of lines...
>


From malenkov at gmail.com  Fri Sep 30 10:58:04 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 13:58:04 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
Message-ID: <CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>

> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>
> The app is crashed as soon as I start scrolling. Investigating...
> May be it is my fault during backporting.

Sorry, It was may fault.


> LWCToolkit.m:
> +// SCROLL EVENT MASK
> +#define SCROLL_PHASE_UNSUPPORTED 1
> ...
>
> replace the comment with the following one:
>
> +// TRACKPAD SCROLL EVENT PHASE

I discovered how we should detect mouse event properly: use both
properties phase and momentumPhase.
https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
"The momentumPhase property helps you detect momentum scrolling, in
which the hardware continues to issue scroll wheel events even though
the user is no longer physically scrolling."

if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.

scrolling by trackpad generates the following events:

phase=mayBegan momentumPhase=null
phase=began momentumPhase=null
phase=continued momentumPhase=null
...
phase=continued momentumPhase=null
phase=ended momentumPhase=null
phase=null momentumPhase=began
phase=null momentumPhase=continued
...
phase=null momentumPhase=continued
phase=null momentumPhase=ended

So, we should generate PHASE_UNSUPPORTED only
if ((phase == NULL) && (momentumPhase == NULL))












-- 
Best regards,
Sergey A. Malenkov

From alexandr.scherbatiy at oracle.com  Fri Sep 30 11:25:23 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 15:25:23 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
Message-ID: <413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev.05

The momentumPhase is used to detect the trackpad events.

Thanks,
Alexandr.

On 30/09/16 14:58, Sergey Malenkov wrote:
>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>
>> The app is crashed as soon as I start scrolling. Investigating...
>> May be it is my fault during backporting.
> Sorry, It was may fault.
>
>
>> LWCToolkit.m:
>> +// SCROLL EVENT MASK
>> +#define SCROLL_PHASE_UNSUPPORTED 1
>> ...
>>
>> replace the comment with the following one:
>>
>> +// TRACKPAD SCROLL EVENT PHASE
> I discovered how we should detect mouse event properly: use both
> properties phase and momentumPhase.
> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
> "The momentumPhase property helps you detect momentum scrolling, in
> which the hardware continues to issue scroll wheel events even though
> the user is no longer physically scrolling."
>
> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>
> scrolling by trackpad generates the following events:
>
> phase=mayBegan momentumPhase=null
> phase=began momentumPhase=null
> phase=continued momentumPhase=null
> ...
> phase=continued momentumPhase=null
> phase=ended momentumPhase=null
> phase=null momentumPhase=began
> phase=null momentumPhase=continued
> ...
> phase=null momentumPhase=continued
> phase=null momentumPhase=ended
>
> So, we should generate PHASE_UNSUPPORTED only
> if ((phase == NULL) && (momentumPhase == NULL))
>
>
>
>
>
>
>
>
>
>
>
>


From ajit.ghaisas at oracle.com  Fri Sep 30 11:38:29 2016
From: ajit.ghaisas at oracle.com (Ajit Ghaisas)
Date: Fri, 30 Sep 2016 04:38:29 -0700 (PDT)
Subject: <AWT Dev> [9] Fix for JDK-8058950 : [TESTBUG] There is no F1
 dialog when the case loading, so we can't restore it.
In-Reply-To: <75762609-344b-21c1-32cd-7b96094c4fa9@oracle.com>
References: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>
	<75762609-344b-21c1-32cd-7b96094c4fa9@oracle.com>
Message-ID: <324d8c4f-b9db-40fc-ac53-73c4ccfc7f36@default>

Looking at the issue(JDK-6401700) where this test was introduced, it is clear that this test should run on linux and solaris.
I have updated the test with appropriate @requires tag.
http://cr.openjdk.java.net/~aghaisas/8058950/webrev.01/

Request you to review.

Regards,
Ajit


-----Original Message-----
From: Sergey Bylokhov 
Sent: Thursday, September 29, 2016 6:07 PM
To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte
Subject: Re: [9] Fix for JDK-8058950 : [TESTBUG] There is no F1 dialog when the case loading,so we can't restore it.

Should this test start on OSX? I think we can tweak the platforms via @req tag.

On 21.09.16 21:04, Ajit Ghaisas wrote:
> Hi,
>
> Bug :
>      https://bugs.openjdk.java.net/browse/JDK-8058950
>
> Issue :
>     Minimized test frame cannot be restored.
>
> Fix :
>    1. The test fix is quite simple - to introduce delay between frame.setVisible(true) and frame.setExtendedState(Frame.ICONIFIED).
>    2. I have modified test - not to use Applet. This results in multiple changes when file diff is seen.
>
> Webrev :
>    http://cr.openjdk.java.net/~aghaisas/8058950/webrev.00/
>
> Request you to review.
>
> Regards,
> Ajit
>


--
Best regards, Sergey.

From Sergey.Bylokhov at oracle.com  Fri Sep 30 11:50:41 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Sep 2016 14:50:41 +0300
Subject: <AWT Dev> [9] Fix for JDK-8058950 : [TESTBUG] There is no F1
 dialog when the case loading, so we can't restore it.
In-Reply-To: <324d8c4f-b9db-40fc-ac53-73c4ccfc7f36@default>
References: <0e4e0f25-0045-4fbc-8546-60f12945669e@default>
	<75762609-344b-21c1-32cd-7b96094c4fa9@oracle.com>
	<324d8c4f-b9db-40fc-ac53-73c4ccfc7f36@default>
Message-ID: <51d538c3-53a4-a41d-81f2-67be14836e6a@oracle.com>

Looks fine.

On 30.09.16 14:38, Ajit Ghaisas wrote:
> Looking at the issue(JDK-6401700) where this test was introduced, it is clear that this test should run on linux and solaris.
> I have updated the test with appropriate @requires tag.
> http://cr.openjdk.java.net/~aghaisas/8058950/webrev.01/
>
> Request you to review.
>
> Regards,
> Ajit
>
>
> -----Original Message-----
> From: Sergey Bylokhov
> Sent: Thursday, September 29, 2016 6:07 PM
> To: Ajit Ghaisas; awt-dev at openjdk.java.net; Semyon Sadetsky; Ambarish Rapte
> Subject: Re: [9] Fix for JDK-8058950 : [TESTBUG] There is no F1 dialog when the case loading,so we can't restore it.
>
> Should this test start on OSX? I think we can tweak the platforms via @req tag.
>
> On 21.09.16 21:04, Ajit Ghaisas wrote:
>> Hi,
>>
>> Bug :
>>      https://bugs.openjdk.java.net/browse/JDK-8058950
>>
>> Issue :
>>     Minimized test frame cannot be restored.
>>
>> Fix :
>>    1. The test fix is quite simple - to introduce delay between frame.setVisible(true) and frame.setExtendedState(Frame.ICONIFIED).
>>    2. I have modified test - not to use Applet. This results in multiple changes when file diff is seen.
>>
>> Webrev :
>>    http://cr.openjdk.java.net/~aghaisas/8058950/webrev.00/
>>
>> Request you to review.
>>
>> Regards,
>> Ajit
>>
>
>
> --
> Best regards, Sergey.
>


-- 
Best regards, Sergey.

From malenkov at gmail.com  Fri Sep 30 12:58:08 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 15:58:08 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
Message-ID: <CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>

In the CPlatformResponder:

phase3 0 ~ 0.0 // mayBegan
phase2 0 ~ 0.0 // began
phase3 0 ~ 0.0222015380859375
phase3 0 ~ 0.0234222412109375
phase3 0 ~ 0.023956298828125
phase3 0 ~ 0.0242919921875
phase3 0 ~ 0.02447509765625
phase3 0 ~ 0.0246124267578125
phase3 0 ~ 0.024658203125
phase3 0 ~ 0.0222015380859375
phase3 0 ~ 0.0233306884765625
phase5 1 ~ 0.0 // end

In Java:

wheelRotation=0,preciseWheelRotation=-0.0222015380859375
wheelRotation=0,preciseWheelRotation=-0.0234222412109375
wheelRotation=0,preciseWheelRotation=-0.023956298828125
wheelRotation=0,preciseWheelRotation=-0.0242919921875
wheelRotation=0,preciseWheelRotation=-0.02447509765625
wheelRotation=0,preciseWheelRotation=-0.0246124267578125
wheelRotation=0,preciseWheelRotation=-0.024658203125
wheelRotation=0,preciseWheelRotation=-0.0222015380859375
wheelRotation=0,preciseWheelRotation=-0.0233306884765625

We ignored first two events, because of 0 & 0.0
We should not ignore last event, where 1 & 0.0
Seems we need to fix DeltaAccumulator.


On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>
> The momentumPhase is used to detect the trackpad events.
>
> Thanks,
> Alexandr.
>
>
> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>
>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>
>>> The app is crashed as soon as I start scrolling. Investigating...
>>> May be it is my fault during backporting.
>>
>> Sorry, It was may fault.
>>
>>
>>> LWCToolkit.m:
>>> +// SCROLL EVENT MASK
>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>> ...
>>>
>>> replace the comment with the following one:
>>>
>>> +// TRACKPAD SCROLL EVENT PHASE
>>
>> I discovered how we should detect mouse event properly: use both
>> properties phase and momentumPhase.
>>
>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>> "The momentumPhase property helps you detect momentum scrolling, in
>> which the hardware continues to issue scroll wheel events even though
>> the user is no longer physically scrolling."
>>
>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>
>> scrolling by trackpad generates the following events:
>>
>> phase=mayBegan momentumPhase=null
>> phase=began momentumPhase=null
>> phase=continued momentumPhase=null
>> ...
>> phase=continued momentumPhase=null
>> phase=ended momentumPhase=null
>> phase=null momentumPhase=began
>> phase=null momentumPhase=continued
>> ...
>> phase=null momentumPhase=continued
>> phase=null momentumPhase=ended
>>
>> So, we should generate PHASE_UNSUPPORTED only
>> if ((phase == NULL) && (momentumPhase == NULL))
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>



-- 
Best regards,
Sergey A. Malenkov

From semyon.sadetsky at oracle.com  Fri Sep 30 14:12:58 2016
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Fri, 30 Sep 2016 17:12:58 +0300
Subject: <AWT Dev> [9] Review request for 8143914: Provide Mac-specific
 fullscreen support
In-Reply-To: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
References: <70a8e894-93be-23d5-a296-2f674053ee1a@oracle.com>
Message-ID: <d873d834-2d46-9d1e-02f1-c01aeac3b100@oracle.com>

The fix looks good.

Do you know why JDialog maximize button doesn't work? When I click on it 
the maximize button the dialog disappears.

--Semyon


On 9/6/2016 5:32 PM, Alexander Zvegintsev wrote:
> Hello,
>
> please review the fix
>
> http://cr.openjdk.java.net/~azvegint/jdk/9/8143914/00/
>
> for the issue
>
> https://bugs.openjdk.java.net/browse/JDK-8143914
>
>
> This fix adds the green FullScreen button to a resizable frames by 
> default.
>
> Previous maximize behavior is still accessible by holding Alt while 
> clicking on the green button.
>
> setResizable is fixed because of two reasons:
>
> Window will not be able to leave fullscreen if we remove resizable 
> from style bits(and even if we set it again)
>
> Window will not have the green button(maximize/zoom or fullscreen) if 
> the window was initially not resizable.
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 30 14:50:51 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Sep 2016 17:50:51 +0300
Subject: <AWT Dev> <Awt Dev> [9] Review Request for 8132664:
 closed/javax/swing/DataTransfer/DefaultNoDrop/DefaultNoDrop.java locks on
 Windows
In-Reply-To: <eb7004ad-2916-1a12-c742-b76076e850e2@oracle.com>
References: <55BF7A25.50301@oracle.com> <55BF8354.7060200@oracle.com>
	<55C0A7EF.80809@oracle.com>
	<16096f2e-ba45-31cf-c322-0668239e931d@oracle.com>
	<eb7004ad-2916-1a12-c742-b76076e850e2@oracle.com>
Message-ID: <ae150c94-eae4-38b1-9741-39979ecc5c4a@oracle.com>

On 29.09.16 18:33, Semyon Sadetsky wrote:
>> Looks fine. Please file separate issue that syncNativeQueue() should
>> check that dnd callbacks are started/completed, because
>> "(newEventNumber - eventNumber) > 2" check is useless if we are in the
>> DND. And if some callbacks are in progress syncNativeQueue() should
>> notify the java side that we should call syncNativeQueue() one more time.
> I have modified the fix to take the above into account. The updated
> webev: http://cr.openjdk.java.net/~ssadetsky/8132664/webrev.02/

Looks fine, Thanks.


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Fri Sep 30 14:59:48 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 18:59:48 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
Message-ID: <7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>


Hello,

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06

- The CPlatformResponder.handleScrollEvent(...) is updated to dispatch  
a scroll event when delta or round delta is not equal to zero
- The native scrollStateWithPhase: method is updated to have NSEvent as 
an argument

Thanks,
Alexandr.

On 30/09/16 16:58, Sergey Malenkov wrote:
> In the CPlatformResponder:
>
> phase3 0 ~ 0.0 // mayBegan
> phase2 0 ~ 0.0 // began
> phase3 0 ~ 0.0222015380859375
> phase3 0 ~ 0.0234222412109375
> phase3 0 ~ 0.023956298828125
> phase3 0 ~ 0.0242919921875
> phase3 0 ~ 0.02447509765625
> phase3 0 ~ 0.0246124267578125
> phase3 0 ~ 0.024658203125
> phase3 0 ~ 0.0222015380859375
> phase3 0 ~ 0.0233306884765625
> phase5 1 ~ 0.0 // end
>
> In Java:
>
> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
> wheelRotation=0,preciseWheelRotation=-0.023956298828125
> wheelRotation=0,preciseWheelRotation=-0.0242919921875
> wheelRotation=0,preciseWheelRotation=-0.02447509765625
> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
> wheelRotation=0,preciseWheelRotation=-0.024658203125
> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>
> We ignored first two events, because of 0 & 0.0
> We should not ignore last event, where 1 & 0.0
> Seems we need to fix DeltaAccumulator.
>
>
> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> Hello,
>>
>> Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>
>> The momentumPhase is used to detect the trackpad events.
>>
>> Thanks,
>> Alexandr.
>>
>>
>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>
>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>> May be it is my fault during backporting.
>>> Sorry, It was may fault.
>>>
>>>
>>>> LWCToolkit.m:
>>>> +// SCROLL EVENT MASK
>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>> ...
>>>>
>>>> replace the comment with the following one:
>>>>
>>>> +// TRACKPAD SCROLL EVENT PHASE
>>> I discovered how we should detect mouse event properly: use both
>>> properties phase and momentumPhase.
>>>
>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>> "The momentumPhase property helps you detect momentum scrolling, in
>>> which the hardware continues to issue scroll wheel events even though
>>> the user is no longer physically scrolling."
>>>
>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>
>>> scrolling by trackpad generates the following events:
>>>
>>> phase=mayBegan momentumPhase=null
>>> phase=began momentumPhase=null
>>> phase=continued momentumPhase=null
>>> ...
>>> phase=continued momentumPhase=null
>>> phase=ended momentumPhase=null
>>> phase=null momentumPhase=began
>>> phase=null momentumPhase=continued
>>> ...
>>> phase=null momentumPhase=continued
>>> phase=null momentumPhase=ended
>>>
>>> So, we should generate PHASE_UNSUPPORTED only
>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 30 15:18:25 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Sep 2016 18:18:25 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
Message-ID: <1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>

What will be the difference if we will scroll by one line at the "begin 
phase"? probably it will be better if the the scroll will start 
immediately on first touch?

On 30.09.16 17:59, Alexander Scherbatiy wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>
> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
> a scroll event when delta or round delta is not equal to zero
> - The native scrollStateWithPhase: method is updated to have NSEvent as
> an argument
>
> Thanks,
> Alexandr.
>
> On 30/09/16 16:58, Sergey Malenkov wrote:
>> In the CPlatformResponder:
>>
>> phase3 0 ~ 0.0 // mayBegan
>> phase2 0 ~ 0.0 // began
>> phase3 0 ~ 0.0222015380859375
>> phase3 0 ~ 0.0234222412109375
>> phase3 0 ~ 0.023956298828125
>> phase3 0 ~ 0.0242919921875
>> phase3 0 ~ 0.02447509765625
>> phase3 0 ~ 0.0246124267578125
>> phase3 0 ~ 0.024658203125
>> phase3 0 ~ 0.0222015380859375
>> phase3 0 ~ 0.0233306884765625
>> phase5 1 ~ 0.0 // end
>>
>> In Java:
>>
>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>
>> We ignored first two events, because of 0 & 0.0
>> We should not ignore last event, where 1 & 0.0
>> Seems we need to fix DeltaAccumulator.
>>
>>
>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>> <alexandr.scherbatiy at oracle.com> wrote:
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>
>>> The momentumPhase is used to detect the trackpad events.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>
>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>> May be it is my fault during backporting.
>>>> Sorry, It was may fault.
>>>>
>>>>
>>>>> LWCToolkit.m:
>>>>> +// SCROLL EVENT MASK
>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>> ...
>>>>>
>>>>> replace the comment with the following one:
>>>>>
>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>> I discovered how we should detect mouse event properly: use both
>>>> properties phase and momentumPhase.
>>>>
>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>
>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>> which the hardware continues to issue scroll wheel events even though
>>>> the user is no longer physically scrolling."
>>>>
>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>
>>>> scrolling by trackpad generates the following events:
>>>>
>>>> phase=mayBegan momentumPhase=null
>>>> phase=began momentumPhase=null
>>>> phase=continued momentumPhase=null
>>>> ...
>>>> phase=continued momentumPhase=null
>>>> phase=ended momentumPhase=null
>>>> phase=null momentumPhase=began
>>>> phase=null momentumPhase=continued
>>>> ...
>>>> phase=null momentumPhase=continued
>>>> phase=null momentumPhase=ended
>>>>
>>>> So, we should generate PHASE_UNSUPPORTED only
>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>


-- 
Best regards, Sergey.

From malenkov at gmail.com  Fri Sep 30 15:33:22 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 18:33:22 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
Message-ID: <CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>

I'm not sure. It can be a "false" scrolling when you accidentally
touched a Magic Mouse.
I think we should use threshold on the phase end, to ignore
accumulatedDelta less than 0.1


On Fri, Sep 30, 2016 at 6:18 PM, Sergey Bylokhov
<Sergey.Bylokhov at oracle.com> wrote:
> What will be the difference if we will scroll by one line at the "begin
> phase"? probably it will be better if the the scroll will start immediately
> on first touch?
>
>
> On 30.09.16 17:59, Alexander Scherbatiy wrote:
>>
>>
>> Hello,
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>
>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
>> a scroll event when delta or round delta is not equal to zero
>> - The native scrollStateWithPhase: method is updated to have NSEvent as
>> an argument
>>
>> Thanks,
>> Alexandr.
>>
>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>>
>>> In the CPlatformResponder:
>>>
>>> phase3 0 ~ 0.0 // mayBegan
>>> phase2 0 ~ 0.0 // began
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0234222412109375
>>> phase3 0 ~ 0.023956298828125
>>> phase3 0 ~ 0.0242919921875
>>> phase3 0 ~ 0.02447509765625
>>> phase3 0 ~ 0.0246124267578125
>>> phase3 0 ~ 0.024658203125
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0233306884765625
>>> phase5 1 ~ 0.0 // end
>>>
>>> In Java:
>>>
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>
>>> We ignored first two events, because of 0 & 0.0
>>> We should not ignore last event, where 1 & 0.0
>>> Seems we need to fix DeltaAccumulator.
>>>
>>>
>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>
>>>> The momentumPhase is used to detect the trackpad events.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>
>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>>
>>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>>
>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>> May be it is my fault during backporting.
>>>>>
>>>>> Sorry, It was may fault.
>>>>>
>>>>>
>>>>>> LWCToolkit.m:
>>>>>> +// SCROLL EVENT MASK
>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>> ...
>>>>>>
>>>>>> replace the comment with the following one:
>>>>>>
>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>>
>>>>> I discovered how we should detect mouse event properly: use both
>>>>> properties phase and momentumPhase.
>>>>>
>>>>>
>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>>
>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>> which the hardware continues to issue scroll wheel events even though
>>>>> the user is no longer physically scrolling."
>>>>>
>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>
>>>>> scrolling by trackpad generates the following events:
>>>>>
>>>>> phase=mayBegan momentumPhase=null
>>>>> phase=began momentumPhase=null
>>>>> phase=continued momentumPhase=null
>>>>> ...
>>>>> phase=continued momentumPhase=null
>>>>> phase=ended momentumPhase=null
>>>>> phase=null momentumPhase=began
>>>>> phase=null momentumPhase=continued
>>>>> ...
>>>>> phase=null momentumPhase=continued
>>>>> phase=null momentumPhase=ended
>>>>>
>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
> --
> Best regards, Sergey.



-- 
Best regards,
Sergey A. Malenkov

From malenkov at gmail.com  Fri Sep 30 15:43:20 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 18:43:20 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
Message-ID: <CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>

+ (jint) scrollStateWithEvent: (NSEvent*) event {

scrollPhaseFromEvent sounds more clear for me

    if ([event type] != NSScrollWheel) {
        return 0;
    }

We have no corresponding SCROLL_PHASE_ constant.
This value is not processed and is processed like S_P_CONTINUED in our code.





On Fri, Sep 30, 2016 at 5:59 PM, Alexander Scherbatiy
<alexandr.scherbatiy at oracle.com> wrote:
>
> Hello,
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>
> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch  a
> scroll event when delta or round delta is not equal to zero
> - The native scrollStateWithPhase: method is updated to have NSEvent as an
> argument
>
> Thanks,
> Alexandr.
>
> On 30/09/16 16:58, Sergey Malenkov wrote:
>>
>> In the CPlatformResponder:
>>
>> phase3 0 ~ 0.0 // mayBegan
>> phase2 0 ~ 0.0 // began
>> phase3 0 ~ 0.0222015380859375
>> phase3 0 ~ 0.0234222412109375
>> phase3 0 ~ 0.023956298828125
>> phase3 0 ~ 0.0242919921875
>> phase3 0 ~ 0.02447509765625
>> phase3 0 ~ 0.0246124267578125
>> phase3 0 ~ 0.024658203125
>> phase3 0 ~ 0.0222015380859375
>> phase3 0 ~ 0.0233306884765625
>> phase5 1 ~ 0.0 // end
>>
>> In Java:
>>
>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>
>> We ignored first two events, because of 0 & 0.0
>> We should not ignore last event, where 1 & 0.0
>> Seems we need to fix DeltaAccumulator.
>>
>>
>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>> <alexandr.scherbatiy at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>
>>> The momentumPhase is used to detect the trackpad events.
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>>
>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>
>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>
>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>> May be it is my fault during backporting.
>>>>
>>>> Sorry, It was may fault.
>>>>
>>>>
>>>>> LWCToolkit.m:
>>>>> +// SCROLL EVENT MASK
>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>> ...
>>>>>
>>>>> replace the comment with the following one:
>>>>>
>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>
>>>> I discovered how we should detect mouse event properly: use both
>>>> properties phase and momentumPhase.
>>>>
>>>>
>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>> which the hardware continues to issue scroll wheel events even though
>>>> the user is no longer physically scrolling."
>>>>
>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>
>>>> scrolling by trackpad generates the following events:
>>>>
>>>> phase=mayBegan momentumPhase=null
>>>> phase=began momentumPhase=null
>>>> phase=continued momentumPhase=null
>>>> ...
>>>> phase=continued momentumPhase=null
>>>> phase=ended momentumPhase=null
>>>> phase=null momentumPhase=began
>>>> phase=null momentumPhase=continued
>>>> ...
>>>> phase=null momentumPhase=continued
>>>> phase=null momentumPhase=ended
>>>>
>>>> So, we should generate PHASE_UNSUPPORTED only
>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>>
>



-- 
Best regards,
Sergey A. Malenkov

From Sergey.Bylokhov at oracle.com  Fri Sep 30 15:45:39 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Sep 2016 18:45:39 +0300
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate InputEvent._MASK in
 favor of InputEvent._DOWN_MASK
Message-ID: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>

Hello.

Please review the fix for jdk9.

This is request to deprecate the obsolete flags inside InputEvent. This 
constants were marked as obsolete in jdk1.4 and were replaced by the new 
one. In jdk1.4 the documentation were update with notion that the new 
constants should be used. And this bug is about official deprecation of 
them.

We can replace old constants by the new one in the whole jdk, but I 
updated only the code in InputEvent to make change smaller and safer. So 
at least the new code in jdk and the code in applications will start to 
use the new constants.

The changes in jconsole are necessary to fix deprecation warning.

jprt build passed, no new issues were found by jck/jtreg tests.


Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00

-- 
Best regards, Sergey.

From malenkov at gmail.com  Fri Sep 30 15:47:06 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 18:47:06 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
Message-ID: <CANTFZ2iXc2dR6B4bifA9tba=DaqfLBPsV-zJLM-cd9WwVNVrFg@mail.gmail.com>

final int roundDelta = isShift && roundDeltaY != 0.0 ? roundDeltaY :
roundDeltaX;

roundDeltaY is integer and should be compared with 0

On Fri, Sep 30, 2016 at 6:43 PM, Sergey Malenkov <malenkov at gmail.com> wrote:
> + (jint) scrollStateWithEvent: (NSEvent*) event {
>
> scrollPhaseFromEvent sounds more clear for me
>
>     if ([event type] != NSScrollWheel) {
>         return 0;
>     }
>
> We have no corresponding SCROLL_PHASE_ constant.
> This value is not processed and is processed like S_P_CONTINUED in our code.
>
>
>
>
>
> On Fri, Sep 30, 2016 at 5:59 PM, Alexander Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>>
>> Hello,
>>
>> Could you review the updated fix:
>>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>
>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch  a
>> scroll event when delta or round delta is not equal to zero
>> - The native scrollStateWithPhase: method is updated to have NSEvent as an
>> argument
>>
>> Thanks,
>> Alexandr.
>>
>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>>
>>> In the CPlatformResponder:
>>>
>>> phase3 0 ~ 0.0 // mayBegan
>>> phase2 0 ~ 0.0 // began
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0234222412109375
>>> phase3 0 ~ 0.023956298828125
>>> phase3 0 ~ 0.0242919921875
>>> phase3 0 ~ 0.02447509765625
>>> phase3 0 ~ 0.0246124267578125
>>> phase3 0 ~ 0.024658203125
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0233306884765625
>>> phase5 1 ~ 0.0 // end
>>>
>>> In Java:
>>>
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>
>>> We ignored first two events, because of 0 & 0.0
>>> We should not ignore last event, where 1 & 0.0
>>> Seems we need to fix DeltaAccumulator.
>>>
>>>
>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>
>>>> The momentumPhase is used to detect the trackpad events.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>
>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>>
>>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>>
>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>> May be it is my fault during backporting.
>>>>>
>>>>> Sorry, It was may fault.
>>>>>
>>>>>
>>>>>> LWCToolkit.m:
>>>>>> +// SCROLL EVENT MASK
>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>> ...
>>>>>>
>>>>>> replace the comment with the following one:
>>>>>>
>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>>
>>>>> I discovered how we should detect mouse event properly: use both
>>>>> properties phase and momentumPhase.
>>>>>
>>>>>
>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>> which the hardware continues to issue scroll wheel events even though
>>>>> the user is no longer physically scrolling."
>>>>>
>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>
>>>>> scrolling by trackpad generates the following events:
>>>>>
>>>>> phase=mayBegan momentumPhase=null
>>>>> phase=began momentumPhase=null
>>>>> phase=continued momentumPhase=null
>>>>> ...
>>>>> phase=continued momentumPhase=null
>>>>> phase=ended momentumPhase=null
>>>>> phase=null momentumPhase=began
>>>>> phase=null momentumPhase=continued
>>>>> ...
>>>>> phase=null momentumPhase=continued
>>>>> phase=null momentumPhase=ended
>>>>>
>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>
>
>
> --
> Best regards,
> Sergey A. Malenkov



-- 
Best regards,
Sergey A. Malenkov

From alexandr.scherbatiy at oracle.com  Fri Sep 30 15:48:08 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 19:48:08 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
	<CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
Message-ID: <5a3f88f2-1cbd-bbda-1b87-9c0455bc0af8@oracle.com>

On 30/09/16 19:33, Sergey Malenkov wrote:
> I'm not sure. It can be a "false" scrolling when you accidentally
> touched a Magic Mouse.
> I think we should use threshold on the phase end, to ignore
> accumulatedDelta less than 0.1

Could you review the updated fix:
   http://cr.openjdk.java.net/~alexsch/8166591/webrev.07

The min threshold is added for the phase end.

Thanks,
Alexandr.
>
>
> On Fri, Sep 30, 2016 at 6:18 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>> What will be the difference if we will scroll by one line at the "begin
>> phase"? probably it will be better if the the scroll will start immediately
>> on first touch?
>>
>>
>> On 30.09.16 17:59, Alexander Scherbatiy wrote:
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>>
>>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
>>> a scroll event when delta or round delta is not equal to zero
>>> - The native scrollStateWithPhase: method is updated to have NSEvent as
>>> an argument
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>>> In the CPlatformResponder:
>>>>
>>>> phase3 0 ~ 0.0 // mayBegan
>>>> phase2 0 ~ 0.0 // began
>>>> phase3 0 ~ 0.0222015380859375
>>>> phase3 0 ~ 0.0234222412109375
>>>> phase3 0 ~ 0.023956298828125
>>>> phase3 0 ~ 0.0242919921875
>>>> phase3 0 ~ 0.02447509765625
>>>> phase3 0 ~ 0.0246124267578125
>>>> phase3 0 ~ 0.024658203125
>>>> phase3 0 ~ 0.0222015380859375
>>>> phase3 0 ~ 0.0233306884765625
>>>> phase5 1 ~ 0.0 // end
>>>>
>>>> In Java:
>>>>
>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>>
>>>> We ignored first two events, because of 0 & 0.0
>>>> We should not ignore last event, where 1 & 0.0
>>>> Seems we need to fix DeltaAccumulator.
>>>>
>>>>
>>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>     http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>>
>>>>> The momentumPhase is used to detect the trackpad events.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>
>>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>>>
>>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>>> May be it is my fault during backporting.
>>>>>> Sorry, It was may fault.
>>>>>>
>>>>>>
>>>>>>> LWCToolkit.m:
>>>>>>> +// SCROLL EVENT MASK
>>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>>> ...
>>>>>>>
>>>>>>> replace the comment with the following one:
>>>>>>>
>>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>>> I discovered how we should detect mouse event properly: use both
>>>>>> properties phase and momentumPhase.
>>>>>>
>>>>>>
>>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>>>
>>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>>> which the hardware continues to issue scroll wheel events even though
>>>>>> the user is no longer physically scrolling."
>>>>>>
>>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>>
>>>>>> scrolling by trackpad generates the following events:
>>>>>>
>>>>>> phase=mayBegan momentumPhase=null
>>>>>> phase=began momentumPhase=null
>>>>>> phase=continued momentumPhase=null
>>>>>> ...
>>>>>> phase=continued momentumPhase=null
>>>>>> phase=ended momentumPhase=null
>>>>>> phase=null momentumPhase=began
>>>>>> phase=null momentumPhase=continued
>>>>>> ...
>>>>>> phase=null momentumPhase=continued
>>>>>> phase=null momentumPhase=ended
>>>>>>
>>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>
>> --
>> Best regards, Sergey.
>
>


From Sergey.Bylokhov at oracle.com  Fri Sep 30 15:48:54 2016
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 30 Sep 2016 18:48:54 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
	<CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
Message-ID: <553d3edd-165b-add8-a000-4ad283628479@oracle.com>

On 30.09.16 18:33, Sergey Malenkov wrote:
> I'm not sure. It can be a "false" scrolling when you accidentally
> touched a Magic Mouse.

The same "false" can occur at the "end" stage, also?

> I think we should use threshold on the phase end, to ignore
> accumulatedDelta less than 0.1
>
>
> On Fri, Sep 30, 2016 at 6:18 PM, Sergey Bylokhov
> <Sergey.Bylokhov at oracle.com> wrote:
>> What will be the difference if we will scroll by one line at the "begin
>> phase"? probably it will be better if the the scroll will start immediately
>> on first touch?
>>
>>
>> On 30.09.16 17:59, Alexander Scherbatiy wrote:
>>>
>>>
>>> Hello,
>>>
>>> Could you review the updated fix:
>>>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>>
>>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
>>> a scroll event when delta or round delta is not equal to zero
>>> - The native scrollStateWithPhase: method is updated to have NSEvent as
>>> an argument
>>>
>>> Thanks,
>>> Alexandr.
>>>
>>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>>>
>>>> In the CPlatformResponder:
>>>>
>>>> phase3 0 ~ 0.0 // mayBegan
>>>> phase2 0 ~ 0.0 // began
>>>> phase3 0 ~ 0.0222015380859375
>>>> phase3 0 ~ 0.0234222412109375
>>>> phase3 0 ~ 0.023956298828125
>>>> phase3 0 ~ 0.0242919921875
>>>> phase3 0 ~ 0.02447509765625
>>>> phase3 0 ~ 0.0246124267578125
>>>> phase3 0 ~ 0.024658203125
>>>> phase3 0 ~ 0.0222015380859375
>>>> phase3 0 ~ 0.0233306884765625
>>>> phase5 1 ~ 0.0 // end
>>>>
>>>> In Java:
>>>>
>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>>
>>>> We ignored first two events, because of 0 & 0.0
>>>> We should not ignore last event, where 1 & 0.0
>>>> Seems we need to fix DeltaAccumulator.
>>>>
>>>>
>>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> Could you review the updated fix:
>>>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>>
>>>>> The momentumPhase is used to detect the trackpad events.
>>>>>
>>>>> Thanks,
>>>>> Alexandr.
>>>>>
>>>>>
>>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>>>
>>>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>>>
>>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>>> May be it is my fault during backporting.
>>>>>>
>>>>>> Sorry, It was may fault.
>>>>>>
>>>>>>
>>>>>>> LWCToolkit.m:
>>>>>>> +// SCROLL EVENT MASK
>>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>>> ...
>>>>>>>
>>>>>>> replace the comment with the following one:
>>>>>>>
>>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>>>
>>>>>> I discovered how we should detect mouse event properly: use both
>>>>>> properties phase and momentumPhase.
>>>>>>
>>>>>>
>>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>>>
>>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>>> which the hardware continues to issue scroll wheel events even though
>>>>>> the user is no longer physically scrolling."
>>>>>>
>>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>>
>>>>>> scrolling by trackpad generates the following events:
>>>>>>
>>>>>> phase=mayBegan momentumPhase=null
>>>>>> phase=began momentumPhase=null
>>>>>> phase=continued momentumPhase=null
>>>>>> ...
>>>>>> phase=continued momentumPhase=null
>>>>>> phase=ended momentumPhase=null
>>>>>> phase=null momentumPhase=began
>>>>>> phase=null momentumPhase=continued
>>>>>> ...
>>>>>> phase=null momentumPhase=continued
>>>>>> phase=null momentumPhase=ended
>>>>>>
>>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>>
>> --
>> Best regards, Sergey.
>
>
>


-- 
Best regards, Sergey.

From alexandr.scherbatiy at oracle.com  Fri Sep 30 15:58:57 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 19:58:57 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
Message-ID: <db198cb7-bef9-8aef-deab-e56488c68c7c@oracle.com>

On 30/09/16 19:43, Sergey Malenkov wrote:
> + (jint) scrollStateWithEvent: (NSEvent*) event {
>
> scrollPhaseFromEvent sounds more clear for me
>
>      if ([event type] != NSScrollWheel) {
>          return 0;
>      }
>
> We have no corresponding SCROLL_PHASE_ constant.
> This value is not processed and is processed like S_P_CONTINUED in our code.
  We do not process it because it is not the NSScrollWheel event and it 
is not handled as a scroll event on the Java level 
(CPlatformResponder.handleScrollEvent(...) is not called).

Thanks,
Alexandr.

>
>
>
>
>
> On Fri, Sep 30, 2016 at 5:59 PM, Alexander Scherbatiy
> <alexandr.scherbatiy at oracle.com> wrote:
>> Hello,
>>
>> Could you review the updated fix:
>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>
>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch  a
>> scroll event when delta or round delta is not equal to zero
>> - The native scrollStateWithPhase: method is updated to have NSEvent as an
>> argument
>>
>> Thanks,
>> Alexandr.
>>
>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>> In the CPlatformResponder:
>>>
>>> phase3 0 ~ 0.0 // mayBegan
>>> phase2 0 ~ 0.0 // began
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0234222412109375
>>> phase3 0 ~ 0.023956298828125
>>> phase3 0 ~ 0.0242919921875
>>> phase3 0 ~ 0.02447509765625
>>> phase3 0 ~ 0.0246124267578125
>>> phase3 0 ~ 0.024658203125
>>> phase3 0 ~ 0.0222015380859375
>>> phase3 0 ~ 0.0233306884765625
>>> phase5 1 ~ 0.0 // end
>>>
>>> In Java:
>>>
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>
>>> We ignored first two events, because of 0 & 0.0
>>> We should not ignore last event, where 1 & 0.0
>>> Seems we need to fix DeltaAccumulator.
>>>
>>>
>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>     http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>
>>>> The momentumPhase is used to detect the trackpad events.
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>>
>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>> # C  [AppKit+0x3a528e]  -[NSApplication _crashOnException:]+0x6d
>>>>>>
>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>> May be it is my fault during backporting.
>>>>> Sorry, It was may fault.
>>>>>
>>>>>
>>>>>> LWCToolkit.m:
>>>>>> +// SCROLL EVENT MASK
>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>> ...
>>>>>>
>>>>>> replace the comment with the following one:
>>>>>>
>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>> I discovered how we should detect mouse event properly: use both
>>>>> properties phase and momentumPhase.
>>>>>
>>>>>
>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>> which the hardware continues to issue scroll wheel events even though
>>>>> the user is no longer physically scrolling."
>>>>>
>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>
>>>>> scrolling by trackpad generates the following events:
>>>>>
>>>>> phase=mayBegan momentumPhase=null
>>>>> phase=began momentumPhase=null
>>>>> phase=continued momentumPhase=null
>>>>> ...
>>>>> phase=continued momentumPhase=null
>>>>> phase=ended momentumPhase=null
>>>>> phase=null momentumPhase=began
>>>>> phase=null momentumPhase=continued
>>>>> ...
>>>>> phase=null momentumPhase=continued
>>>>> phase=null momentumPhase=ended
>>>>>
>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>
>


From malenkov at gmail.com  Fri Sep 30 16:00:28 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 19:00:28 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <553d3edd-165b-add8-a000-4ad283628479@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
	<CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
	<553d3edd-165b-add8-a000-4ad283628479@oracle.com>
Message-ID: <CANTFZ2jeHnnR0Uj-QVYFMUj=4z=XEuikHGeyu0YECYef3Wz80A@mail.gmail.com>

>> I'm not sure. It can be a "false" scrolling when you accidentally
>> touched a Magic Mouse.
>
> The same "false" can occur at the "end" stage, also?

Yes, but at the "end" we can use a threshold. See below:

>> I think we should use threshold on the phase end, to ignore
>> accumulatedDelta less than 0.1

-- 
Best regards,
Sergey A. Malenkov

From mandy.chung at oracle.com  Fri Sep 30 16:01:41 2016
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 30 Sep 2016 09:01:41 -0700
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate
	InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
Message-ID: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com>

The jconsole change looks fine.  I?m including serviceability-dev and bcc core-libs-dev as serviceability-dev is the right mailing list for jconsole change.

Mandy

> On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
> 
> Hello.
> 
> Please review the fix for jdk9.
> 
> This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them.
> 
> We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants.
> 
> The changes in jconsole are necessary to fix deprecation warning.
> 
> jprt build passed, no new issues were found by jck/jtreg tests.
> 
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00
> 
> -- 
> Best regards, Sergey.


From alexandr.scherbatiy at oracle.com  Fri Sep 30 16:45:19 2016
From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy)
Date: Fri, 30 Sep 2016 20:45:19 +0400
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <5a3f88f2-1cbd-bbda-1b87-9c0455bc0af8@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<1ab5e660-79db-7baa-78c7-065ab603e915@oracle.com>
	<CANTFZ2gaBGNLWC3Js4XRQ6ChBEfq5mKJOewBHT_t3yoNUYMAkw@mail.gmail.com>
	<5a3f88f2-1cbd-bbda-1b87-9c0455bc0af8@oracle.com>
Message-ID: <ea35bcc7-935f-e423-a740-7591ce92aa44@oracle.com>

On 30/09/16 19:48, Alexander Scherbatiy wrote:
> On 30/09/16 19:33, Sergey Malenkov wrote:
>> I'm not sure. It can be a "false" scrolling when you accidentally
>> touched a Magic Mouse.
>> I think we should use threshold on the phase end, to ignore
>> accumulatedDelta less than 0.1
>
> Could you review the updated fix:
>   http://cr.openjdk.java.net/~alexsch/8166591/webrev.07
>
> The min threshold is added for the phase end.
   Here is the updated version where the accumulated delta is not reset 
at the phase end:
     http://cr.openjdk.java.net/~alexsch/8166591/webrev.08

   Thanks,
   Alexandr.

>
> Thanks,
> Alexandr.
>>
>>
>> On Fri, Sep 30, 2016 at 6:18 PM, Sergey Bylokhov
>> <Sergey.Bylokhov at oracle.com> wrote:
>>> What will be the difference if we will scroll by one line at the "begin
>>> phase"? probably it will be better if the the scroll will start 
>>> immediately
>>> on first touch?
>>>
>>>
>>> On 30.09.16 17:59, Alexander Scherbatiy wrote:
>>>>
>>>> Hello,
>>>>
>>>> Could you review the updated fix:
>>>>    http://cr.openjdk.java.net/~alexsch/8166591/webrev.06
>>>>
>>>> - The CPlatformResponder.handleScrollEvent(...) is updated to dispatch
>>>> a scroll event when delta or round delta is not equal to zero
>>>> - The native scrollStateWithPhase: method is updated to have 
>>>> NSEvent as
>>>> an argument
>>>>
>>>> Thanks,
>>>> Alexandr.
>>>>
>>>> On 30/09/16 16:58, Sergey Malenkov wrote:
>>>>> In the CPlatformResponder:
>>>>>
>>>>> phase3 0 ~ 0.0 // mayBegan
>>>>> phase2 0 ~ 0.0 // began
>>>>> phase3 0 ~ 0.0222015380859375
>>>>> phase3 0 ~ 0.0234222412109375
>>>>> phase3 0 ~ 0.023956298828125
>>>>> phase3 0 ~ 0.0242919921875
>>>>> phase3 0 ~ 0.02447509765625
>>>>> phase3 0 ~ 0.0246124267578125
>>>>> phase3 0 ~ 0.024658203125
>>>>> phase3 0 ~ 0.0222015380859375
>>>>> phase3 0 ~ 0.0233306884765625
>>>>> phase5 1 ~ 0.0 // end
>>>>>
>>>>> In Java:
>>>>>
>>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>>> wheelRotation=0,preciseWheelRotation=-0.0234222412109375
>>>>> wheelRotation=0,preciseWheelRotation=-0.023956298828125
>>>>> wheelRotation=0,preciseWheelRotation=-0.0242919921875
>>>>> wheelRotation=0,preciseWheelRotation=-0.02447509765625
>>>>> wheelRotation=0,preciseWheelRotation=-0.0246124267578125
>>>>> wheelRotation=0,preciseWheelRotation=-0.024658203125
>>>>> wheelRotation=0,preciseWheelRotation=-0.0222015380859375
>>>>> wheelRotation=0,preciseWheelRotation=-0.0233306884765625
>>>>>
>>>>> We ignored first two events, because of 0 & 0.0
>>>>> We should not ignore last event, where 1 & 0.0
>>>>> Seems we need to fix DeltaAccumulator.
>>>>>
>>>>>
>>>>> On Fri, Sep 30, 2016 at 2:25 PM, Alexander Scherbatiy
>>>>> <alexandr.scherbatiy at oracle.com> wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Could you review the updated fix:
>>>>>> http://cr.openjdk.java.net/~alexsch/8166591/webrev.05
>>>>>>
>>>>>> The momentumPhase is used to detect the trackpad events.
>>>>>>
>>>>>> Thanks,
>>>>>> Alexandr.
>>>>>>
>>>>>>
>>>>>> On 30/09/16 14:58, Sergey Malenkov wrote:
>>>>>>>> # C  [AppKit+0x3a528e] -[NSApplication _crashOnException:]+0x6d
>>>>>>>>
>>>>>>>> The app is crashed as soon as I start scrolling. Investigating...
>>>>>>>> May be it is my fault during backporting.
>>>>>>> Sorry, It was may fault.
>>>>>>>
>>>>>>>
>>>>>>>> LWCToolkit.m:
>>>>>>>> +// SCROLL EVENT MASK
>>>>>>>> +#define SCROLL_PHASE_UNSUPPORTED 1
>>>>>>>> ...
>>>>>>>>
>>>>>>>> replace the comment with the following one:
>>>>>>>>
>>>>>>>> +// TRACKPAD SCROLL EVENT PHASE
>>>>>>> I discovered how we should detect mouse event properly: use both
>>>>>>> properties phase and momentumPhase.
>>>>>>>
>>>>>>>
>>>>>>> https://developer.apple.com/library/prerelease/content/documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html 
>>>>>>>
>>>>>>>
>>>>>>> "The momentumPhase property helps you detect momentum scrolling, in
>>>>>>> which the hardware continues to issue scroll wheel events even 
>>>>>>> though
>>>>>>> the user is no longer physically scrolling."
>>>>>>>
>>>>>>> if (phase==NULL) && (momentumPhase==NULL) -> this is a mouse event.
>>>>>>>
>>>>>>> scrolling by trackpad generates the following events:
>>>>>>>
>>>>>>> phase=mayBegan momentumPhase=null
>>>>>>> phase=began momentumPhase=null
>>>>>>> phase=continued momentumPhase=null
>>>>>>> ...
>>>>>>> phase=continued momentumPhase=null
>>>>>>> phase=ended momentumPhase=null
>>>>>>> phase=null momentumPhase=began
>>>>>>> phase=null momentumPhase=continued
>>>>>>> ...
>>>>>>> phase=null momentumPhase=continued
>>>>>>> phase=null momentumPhase=ended
>>>>>>>
>>>>>>> So, we should generate PHASE_UNSUPPORTED only
>>>>>>> if ((phase == NULL) && (momentumPhase == NULL))
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>
>>> -- 
>>> Best regards, Sergey.
>>
>>
>


From malenkov at gmail.com  Fri Sep 30 17:36:22 2016
From: malenkov at gmail.com (Sergey Malenkov)
Date: Fri, 30 Sep 2016 20:36:22 +0300
Subject: <AWT Dev> [9] Review request for 8166591 [macos 10.12] Trackpad
 scrolling of text on OS X 10.12 Sierra is very fast (Trackpad, Retina only)
In-Reply-To: <cfefbc8a-b088-107d-4330-aecbb3f53120@oracle.com>
References: <00a75e11-d8a9-88cb-7703-9415393c9957@oracle.com>
	<c115b04b-615a-c21b-292a-a0832eb8abf7@oracle.com>
	<CANTFZ2hTH7DHUhEWsxzb1WcRxU0_o3W2dBw2c6S=MrzMVkxjfA@mail.gmail.com>
	<817543bc-c791-eb43-3430-b27acd23f386@oracle.com>
	<CANTFZ2g=8L+QdSTnA7myRP=+Omndk4ZL01nJ1Lzg2e0zrp+9+w@mail.gmail.com>
	<8eaa121e-97fe-31ee-f1da-d1ae98b70878@oracle.com>
	<CANTFZ2jYXN7k5+7RFQpnHv=uLSjS1YnDdTVjSB1SzWQBEp-ODQ@mail.gmail.com>
	<CANTFZ2ghFnUJ6CWcYiwRbLq+tj5xB1S5dKqi85fV+EdyAXqQqQ@mail.gmail.com>
	<413b5107-81b2-20ee-2efb-a5fa4480150f@oracle.com>
	<CANTFZ2ieCBgAVkvyXi6MY5y17-foN4tE50MOBKKV1eX9doET4g@mail.gmail.com>
	<7274b203-4648-e2b2-356c-2f70883395ea@oracle.com>
	<CANTFZ2iBRcYuwUs7dWU4ANJsu6oCDVNyVPGnqHK+_pTN-W45dA@mail.gmail.com>
	<db198cb7-bef9-8aef-deab-e56488c68c7c@oracle.com>
	<CANTFZ2gn1bzQv94EniHyjpBDDXtDEAx6WQgMmTo-zEtGcS9nLw@mail.gmail.com>
	<daa84af4-6fe3-521a-d4f8-1938e3284850@oracle.com>
	<CANTFZ2gjd4Ak5BHFk2CxOuNpoma=AbxdwrRSvnQgwYJMDJ0=Pg@mail.gmail.com>
	<cfefbc8a-b088-107d-4330-aecbb3f53120@oracle.com>
Message-ID: <CANTFZ2jostnYRRT_Bj_OS=7OuL5LXQ1XaPLte7BpG3rKMt+Eag@mail.gmail.com>

>>>> Also, I can't understand what DELTA_THRESHOLD means?
>>>> It increases a pause before scrolling, which is not comfortable for me.
>>>
>>> Yes. I is just a barrier before which the wheel rotation event is not
>>> counted.
>>
>> The default 0.5 from Math.round is more comfortable.
>>
>> Could you please look for corresponding comments with "deadzone":
>> http://youtrack.jetbrains.com/issue/IDEA-158500
>
>   The updated version where the brgining threshold is set to 0.5:
>     http://cr.openjdk.java.net/~alexsch/8166591/webrev.09

Thank you. Looks good.
Could you please look at the attached patch for 8u?
I used it with our custom jdk to test the behavior.


-- 
Best regards,
Sergey A. Malenkov
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk8uIDEA.patch
Type: application/octet-stream
Size: 12576 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160930/9fb90944/jdk8uIDEA-0001.patch>

From jbluettduncan at gmail.com  Fri Sep 30 16:08:58 2016
From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan)
Date: Fri, 30 Sep 2016 17:08:58 +0100
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
Message-ID: <CAPMys85g4zRP+9G_zS1NMpZGyXYpLqR0jqkodgd+qWcj_JbcFA@mail.gmail.com>

Hi Sergey,

I'm not a reviewer, but after reading the deprecation messages in Event.java

* @deprecated It is recommended that {@code AWTEvent} class and its
> subclasses
> *             be used instead.


I get the impression they would read better without the redundant "class"
in the middle, like so.

* @deprecated It is recommended that {@code AWTEvent} and its subclasses
> *             be used instead.


Kind regards,
Jonathan


On 30 September 2016 at 16:45, Sergey Bylokhov <Sergey.Bylokhov at oracle.com>
wrote:

> Hello.
>
> Please review the fix for jdk9.
>
> This is request to deprecate the obsolete flags inside InputEvent. This
> constants were marked as obsolete in jdk1.4 and were replaced by the new
> one. In jdk1.4 the documentation were update with notion that the new
> constants should be used. And this bug is about official deprecation of
> them.
>
> We can replace old constants by the new one in the whole jdk, but I
> updated only the code in InputEvent to make change smaller and safer. So at
> least the new code in jdk and the code in applications will start to use
> the new constants.
>
> The changes in jconsole are necessary to fix deprecation warning.
>
> jprt build passed, no new issues were found by jck/jtreg tests.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00
>
> --
> Best regards, Sergey.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/awt-dev/attachments/20160930/7ceaa23b/attachment.html>

From erik.gahlin at oracle.com  Fri Sep 30 16:24:08 2016
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Fri, 30 Sep 2016 18:24:08 +0200
Subject: <AWT Dev> [9] Review Request: 8143077 Deprecate
 InputEvent._MASK in favor of InputEvent._DOWN_MASK
In-Reply-To: <38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com>
References: <f0aa606b-0303-0f38-ff8b-f6e3e357d73f@oracle.com>
	<38FC8343-B900-4D18-86AA-D882DD9B9F43@oracle.com>
Message-ID: <57EE91A8.9010808@oracle.com>

Looks good.

Erik

> On Sep 30, 2016, at 8:45 AM, Sergey Bylokhov <Sergey.Bylokhov at oracle.com> wrote:
>
> Hello.
>
> Please review the fix for jdk9.
>
> This is request to deprecate the obsolete flags inside InputEvent. This constants were marked as obsolete in jdk1.4 and were replaced by the new one. In jdk1.4 the documentation were update with notion that the new constants should be used. And this bug is about official deprecation of them.
>
> We can replace old constants by the new one in the whole jdk, but I updated only the code in InputEvent to make change smaller and safer. So at least the new code in jdk and the code in applications will start to use the new constants.
>
> The changes in jconsole are necessary to fix deprecation warning.
>
> jprt build passed, no new issues were found by jck/jtreg tests.
>
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8143077
> Webrev can be found at: http://cr.openjdk.java.net/~serb/8143077/webrev.00
>
> -- 
> Best regards, Sergey.


From philip.race at oracle.com  Fri Sep 30 19:01:38 2016
From: philip.race at oracle.com (Phil Race)
Date: Fri, 30 Sep 2016 12:01:38 -0700
Subject: <AWT Dev> RFR: JDK-8165232 XKeycodeToKeysym is deprecated and
 should be replaced with XkbKeycodeToKeysym
In-Reply-To: <0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
References: <3cedc4fd-ff90-4299-95ed-e8beb424e55e@oracle.com>
	<246e1014-6227-a00a-6464-450ccab63e37@oracle.com>
	<57E7148D.1090803@oracle.com>
	<8b5cdc4f-c24b-2919-3e8e-10676bd42275@oracle.com>
	<57E99AA5.1020704@oracle.com>
	<2fdd04eb-f325-449b-8926-6af7ea7f0b35@oracle.com>
	<57E9A440.70708@oracle.com>
	<0a2b539c-5cc0-e77c-f1e4-982012a0807d@oracle.com>
Message-ID: <936802ec-49cb-8703-0c4c-c53ba4816357@oracle.com>

Our helpful SQE engineer has verified that this works as well as previously.
And I've done some basic testing myself on Ubuntu 16.04, so "+1" 
(meaning approved).

-phil.

On 09/27/2016 08:41 AM, Alan Burlison wrote:
> On 26/09/2016 23:42, Philip Race wrote:
>
>
>>>> So that looks like it should work although the duplicate
>>>> definition irks. Can we remove the static and have it just be
>>>> extern declared in XWindow.c ?
>>>
>>> Absolutely - I didn't particularly like it either but I was a bit
>>> wary of adding a new external symbol. Is the current name OK?
>
> Done, new webrev at http://cr.openjdk.java.net/~alanbur/JDK-8165232.v2/
>
>>>> For testing can you submit a jprt job and I'll see if I can
>>>> rustle up some SQE support to identify any tests that might be
>>>> good to run.
>
> JPRT run on the v2 patch is clean.
>