From serb at openjdk.java.net  Mon Feb  1 09:09:02 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 1 Feb 2021 09:09:02 GMT
Subject: <AWT Dev> RFR: 8260695: The
 java.awt.color.ICC_Profile#getData/getData(int) are not thread safe
Message-ID: <mIErsEj4ASRXv3Jl40TVHsa6uBjyxc4mfqi4pcPsUJc=.7c1f38ec-dcd5-4c18-b0d1-a59c81e6453f@github.com>

Both methods are implemented in a similar way.
 1. Requests the size of the profile/tag data
 2. Creates an array of the correct size
 3. Requests the data and copy it to the array

If the data will be changed concurrently between steps 2. and 3. then we will get a mismatch between the array and copied data. 

In the fix, all steps above are merged to just one step return the data when requested.

-------------

Commit messages:
 - cleanup
 - Merge branch 'JDK-8260695' of https://github.com/mrserb/jdk into JDK-8260695
 - Update LCMSProfile.java
 - Update LCMSProfile.java
 - Create MTGetData.java
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/2330/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2330&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260695
  Stats: 295 lines in 7 files changed: 138 ins; 110 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2330.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2330/head:pull/2330

PR: https://git.openjdk.java.net/jdk/pull/2330

From serb at openjdk.java.net  Mon Feb  1 09:09:03 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 1 Feb 2021 09:09:03 GMT
Subject: <AWT Dev> RFR: 8260695: The
 java.awt.color.ICC_Profile#getData/getData(int) are not thread safe
In-Reply-To: <mIErsEj4ASRXv3Jl40TVHsa6uBjyxc4mfqi4pcPsUJc=.7c1f38ec-dcd5-4c18-b0d1-a59c81e6453f@github.com>
References: <mIErsEj4ASRXv3Jl40TVHsa6uBjyxc4mfqi4pcPsUJc=.7c1f38ec-dcd5-4c18-b0d1-a59c81e6453f@github.com>
Message-ID: <BCs2SzK9whM45f_M7a4KpBdDhOEGSXGbIwFYaIqtLPY=.931348cd-9cb6-4ccb-8a2c-d320f1d27a8c@github.com>

On Mon, 1 Feb 2021 09:00:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Both methods are implemented in a similar way.
>  1. Requests the size of the profile/tag data
>  2. Creates an array of the correct size
>  3. Requests the data and copy it to the array
> 
> If the data will be changed concurrently between steps 2. and 3. then we will get a mismatch between the array and copied data. 
> 
> In the fix, all steps above are merged to just one step return the data when requested.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1210:

> 1208:     public byte[] getData() {
> 1209:         activate();
> 1210:         return CMSManager.getModule().getProfileData(cmmProfile);

Just one step, the array will be created in the native code under proper synchronization.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 1236:

> 1234:     private static byte[] getData(Profile p, int tagSignature) {
> 1235:         try {
> 1236:             return CMSManager.getModule().getTagData(p, tagSignature);

Just one step, the array will be created in the native code under proper synchronization.

src/java.desktop/share/native/liblcms/LCMS.c line 330:

> 328:     }
> 329: 
> 330:     jbyteArray data = (*env)->NewByteArray(env, pfSize);

Here we create the new array.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2330

From ihse at openjdk.java.net  Mon Feb  1 11:37:48 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 1 Feb 2021 11:37:48 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
Message-ID: <rDWnxwyx9QoCTJoc1cx9M_cNXZQEwCJh0__EucoGYZA=.62d1ccbe-6930-4e0a-b7c2-b69f2ce6982d@github.com>

On Fri, 29 Jan 2021 17:24:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260616: Removing remaining JNF dependencies in the java.desktop modul

Build changes look good for this PR.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Mon Feb  1 15:48:54 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 1 Feb 2021 15:48:54 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <rDWnxwyx9QoCTJoc1cx9M_cNXZQEwCJh0__EucoGYZA=.62d1ccbe-6930-4e0a-b7c2-b69f2ce6982d@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
 <rDWnxwyx9QoCTJoc1cx9M_cNXZQEwCJh0__EucoGYZA=.62d1ccbe-6930-4e0a-b7c2-b69f2ce6982d@github.com>
Message-ID: <66cXL2SOExTog6P8mNA89EmA6_5YJZ0t8JklkIVO5eE=.866c4e2a-22f1-4713-8c0c-a658bcffd15c@github.com>

On Mon, 1 Feb 2021 11:35:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Build changes look good for this PR.

> * There is also a test dependency that I have seen being addressed, in `make/test/JtregNativeJdk.gmk` line 82, for `libTestMainKeyWindow`.

update on this. It Is used by precisely one jtreg AWT test. So I guess it is fair game to add resolving this to the desktop module update. I am currently testing it before committing - will take a couple of hours as the headful tests take a while to run.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From gziemski at openjdk.java.net  Mon Feb  1 18:33:44 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 1 Feb 2021 18:33:44 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <Qbm3YYbnAeQycSXj8M4mukJXusNpxlRDTSwWELN6nQM=.e3325063-cf69-4816-adaa-6a54c6a867a1@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <CcTcYbUlEM0fXgnud0sZelIWOEelhDkV3B6fonTivDg=.c9143c70-2899-420a-960c-bde09a3de514@github.com>
 <Qbm3YYbnAeQycSXj8M4mukJXusNpxlRDTSwWELN6nQM=.e3325063-cf69-4816-adaa-6a54c6a867a1@github.com>
Message-ID: <KUhM5A77wS3XJyDmLYR008Dk8AQwhHDO_GBWEcQJAXU=.84dfb468-c96d-4ffc-9b36-50d0b57e228c@github.com>

On Fri, 29 Jan 2021 19:53:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 83:
>> 
>>> 81:                   stringWithFileSystemRepresentation:chs length:len];
>>> 82:     return result;
>>> 83: }
>> 
>> Why are we doing:
>> 
>> `java_string -> chars -> NSString -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
>> 
>> ?
>> 
>> Why not just get the raw characters form JNI and feed them directly into `[NSFileManager  stringWithFileSystemRepresentation]`, ie:
>> 
>> `java_string -> chars -> [NSFileManager stringWithFileSystemRepresentation]`
>> 
>> and skip the `JavaStringToNSString` step altogether?
>
> I tried to explain the odd-ness of this in the comments preceding the function definition.
> Near as I could figure out that intermediate call is needed to do the decomposition since the NSFileManager won't do that.
> But this is not exactly my area of expertise and there may be a better way. Who is an expert on the intricacies of the macOS file system naming ?

How about a comment like:

/*
 Returns an NSString in decomposed UTF16 format that is compatible with HFS's
 expectation of the UTF16 format for file system paths.
 
 Example string: "/Users/Am?lie/"
 
 Java's UTF16 string is                 "/ U s e r s / A m \351 l i e /"
 macOS UTF16 string suitable for HFS is "/ U s e r s / A m e \314 \201 l i e /"
 
 There is no direct API that takes in NSString UTF16 encoded by Java
 and produces NSString UTF16 for HFS, so we first need to decompose it
 into chars (suitable for low level C file APIs), and only then
 create NSString representation of this decomposition back into UTF16 string.
 */

?

I borrowed the API description from Apple's original `JNFNormalizedNSStringForPath` API, but added an example and different description.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From gziemski at openjdk.java.net  Mon Feb  1 18:33:42 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 1 Feb 2021 18:33:42 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
Message-ID: <jeQG24bC4F5ckJaMUCytdXBnXQNRrWG6GSJJ5ykH4RM=.a5aa45f2-f08c-4c3e-9e66-e61bda1017e5@github.com>

On Fri, 29 Jan 2021 17:24:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260616: Removing remaining JNF dependencies in the java.desktop modul

Marked as reviewed by gziemski (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From gziemski at openjdk.java.net  Mon Feb  1 18:36:46 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 1 Feb 2021 18:36:46 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <jeQG24bC4F5ckJaMUCytdXBnXQNRrWG6GSJJ5ykH4RM=.a5aa45f2-f08c-4c3e-9e66-e61bda1017e5@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
 <jeQG24bC4F5ckJaMUCytdXBnXQNRrWG6GSJJ5ykH4RM=.a5aa45f2-f08c-4c3e-9e66-e61bda1017e5@github.com>
Message-ID: <NPMa9L7BQsZZDJ7XFLb9360ye-GOkN8fERMrWejNYvA=.549d405c-aa04-48ed-9c47-e6cf9f640600@github.com>

On Mon, 1 Feb 2021 18:31:23 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260616: Removing remaining JNF dependencies in the java.desktop modul
>
> Marked as reviewed by gziemski (Committer).

The changes look good to me, but please see my comment from my review about documenting `NormalizedPathNSStringFromJavaString()` API.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Mon Feb  1 19:09:59 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 1 Feb 2021 19:09:59 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8260616: Removing remaining JNF dependencies in the java.desktop module

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2305/files
  - new: https://git.openjdk.java.net/jdk/pull/2305/files/efab1de5..7ea57c85

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=01-02

  Stats: 46 lines in 3 files changed: 34 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305

PR: https://git.openjdk.java.net/jdk/pull/2305

From serb at openjdk.java.net  Mon Feb  1 22:51:47 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 1 Feb 2021 22:51:47 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
Message-ID: <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>

On Mon, 1 Feb 2021 19:09:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8260616: Removing remaining JNF dependencies in the java.desktop module

src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 611:

> 609:         const jchar *unichars = (*env)->GetStringChars(env, str, NULL);
> 610:         if (unichars == NULL) {
> 611:             return;

Do not we need to throw an exception here? Otherwise, GetStringChars error will be ignored?

src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 967:

> 965: static NSNumber* JavaNumberToNSNumber(JNIEnv *env, jobject jnumber) {
> 966:     if (jnumber == NULL) {
> 967:         return nil;

Based on its usage it is probably should be zero on NULL number?

src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 30:

> 28: NSString* JavaStringToNSString(JNIEnv *env, jstring jstr) {
> 29:     if (jstr == NULL) {
> 30:         return NULL;

In other methods, the nil is used

src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53:

> 51: @implementation ThreadUtilities
> 52: 
> 53: + (void)initialize {

I think we need to check how this new modes will work when the AWT is embedded inside SWT and FX.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From dcubed at openjdk.java.net  Mon Feb  1 23:21:51 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 1 Feb 2021 23:21:51 GMT
Subject: <AWT Dev> RFR: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
Message-ID: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>

A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
in order to reduce the noise in the JDK17 CI.

-------------

Commit messages:
 - 8260867: ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux

Changes: https://git.openjdk.java.net/jdk/pull/2344/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2344&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260867
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2344.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2344/head:pull/2344

PR: https://git.openjdk.java.net/jdk/pull/2344

From prr at openjdk.java.net  Tue Feb  2 00:32:46 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 00:32:46 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
Message-ID: <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>

On Mon, 1 Feb 2021 22:17:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8260616: Removing remaining JNF dependencies in the java.desktop module
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 611:
> 
>> 609:         const jchar *unichars = (*env)->GetStringChars(env, str, NULL);
>> 610:         if (unichars == NULL) {
>> 611:             return;
> 
> Do not we need to throw an exception here? Otherwise, GetStringChars error will be ignored?

Look a few lines further up at my reply 3 days ago Gerard about this.

> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 967:
> 
>> 965: static NSNumber* JavaNumberToNSNumber(JNIEnv *env, jobject jnumber) {
>> 966:     if (jnumber == NULL) {
>> 967:         return nil;
> 
> Based on its usage it is probably should be zero on NULL number?

Not an unreasonable idea and I considered it but :
- It is never called with NULL. There is always a null check
- The JNF equivalent returns nil on NULL

BTW two of the functions in which the code appears : accessibilityMinValueAttribute and accessibilityMaxValueAttribute  (SFAIC) aren't used anywhere.

> src/java.desktop/macosx/native/libosxapp/JNIUtilities.m line 30:
> 
>> 28: NSString* JavaStringToNSString(JNIEnv *env, jstring jstr) {
>> 29:     if (jstr == NULL) {
>> 30:         return NULL;
> 
> In other methods, the nil is used

Not understanding what you mean ? This is the same behavior as the function being replaced.

> src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53:
> 
>> 51: @implementation ThreadUtilities
>> 52: 
>> 53: + (void)initialize {
> 
> I think we need to check how this new modes will work when the AWT is embedded inside SWT and FX.

We are just specifying an additional run mode for JDK internal use.
It means that when we are saying to process only events for that mode, then only those will be processed.
And it is used only for nested event loops.
Nothing eternal should be assuming AWT uses JNF at all, never mind in a particular way.

There is a special case for FX but I don't see a problem.

If you look at Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl
there's a variable "inAWT".
         isRunning = [[NSRunLoop currentRunLoop] runMode:(inAWT ? [JNFRunLoop javaRunLoopMode] : NSDefaultRunLoopMode) ... ]];

This is specified as
        inAWT = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
            @Override
            public Boolean run() {
                return !Boolean.parseBoolean(System.getProperty("javafx.embed.singleThread", "false"));
            }
        });
    }

So generally FX doesn't care, and is ignorant of this new mode.
Unless you set that property to true, in which case AWT use the  NSDefaultRunLoopMode and so again FX is unaffected.
Nothing in the FX sources goes anywhere near JNF .. or has a reference to the special mode.

Bottom line I don't see it being affected. 

I'll check with Kevin but also Gerard had a lot to do with the creation of the current FX toolkit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From psadhukhan at openjdk.java.net  Tue Feb  2 04:08:39 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 2 Feb 2021 04:08:39 GMT
Subject: <AWT Dev> RFR: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
In-Reply-To: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
References: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
Message-ID: <0qdYH8O7XHTt64NKuaBcOnliQ2V5R5os7x2OC2g2bAg=.4aac8fb6-081e-4321-806d-7eb71e51f6a9@github.com>

On Mon, 1 Feb 2021 23:16:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
> in order to reduce the noise in the JDK17 CI.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2344

From jdv at openjdk.java.net  Tue Feb  2 04:12:41 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 2 Feb 2021 04:12:41 GMT
Subject: <AWT Dev> RFR: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
In-Reply-To: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
References: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
Message-ID: <cQc4GPF-bxww9mRr91Mt3UG0KsCqFvPF43zohOD2B2I=.f9bca712-c55e-42a9-b9f3-0b2164cf5a61@github.com>

On Mon, 1 Feb 2021 23:16:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
> in order to reduce the noise in the JDK17 CI.

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2344

From pbansal at openjdk.java.net  Tue Feb  2 07:15:42 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Tue, 2 Feb 2021 07:15:42 GMT
Subject: <AWT Dev> RFR: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
In-Reply-To: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
References: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
Message-ID: <7guSTOgWszoD8wmhD5j_yOfMl4SMhYLlKbdcAUWRnqI=.26e5165d-4592-4571-a9a8-403f1fc7b3d4@github.com>

On Mon, 1 Feb 2021 23:16:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
> in order to reduce the noise in the JDK17 CI.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2344

From kizune at openjdk.java.net  Tue Feb  2 12:56:47 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 2 Feb 2021 12:56:47 GMT
Subject: <AWT Dev> RFR: 8076313: GraphicsEnvironment does not detect
 changes in count of monitors on Linux OS
In-Reply-To: <JhSf4DUgF9_Wc-_4u3t0pNXxdg-elLn8hr0VhOqkn8g=.07ea8917-7a72-40c5-a4b1-97240fcc0584@github.com>
References: <JhSf4DUgF9_Wc-_4u3t0pNXxdg-elLn8hr0VhOqkn8g=.07ea8917-7a72-40c5-a4b1-97240fcc0584@github.com>
Message-ID: <iW38xSEHt_moV0EhHhRipyh6YLlG6a1BFcwUyB-4n2E=.839015bf-06ed-4b5a-b204-0115924c68d1@github.com>

On Tue, 26 Jan 2021 04:08:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This fix enables display change detection on Linux when the number of monitors is changed in the Xinerama mode.
> 
> The fix itself is straightforward:
> 1. When we get an event that the root window is changed we assume that it could be caused by some screen manipulation like screen resolution change or adding/removing a monitor.
> 2. We rebuild the native data structure for the x11 screens, and then mirror this data on the java level in the X11GraphicsEnvironment.
> 3. While we updating the data, we block all access to it in the native -> after the fix all access to the native x11 screens should be done under awt-lock.
> 
> Notes:
>  - This fix has a long chain of pre-fixes where we dropped the native access to the x11 screens, to minimize the places we need to synchronize.
>  - In the current version we rebuild the screens more often than needed, for example, we rebuild it even if resolution changed in a single monitor config. It is done intentionally to increase the test code coverage for now.
>  - The current implementation is based on the Xinerama, while the better solution will be use XRandr 1.5, but it does not support AIX, and is not supported in the current devkit.

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2230

From dcubed at openjdk.java.net  Tue Feb  2 15:39:57 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 2 Feb 2021 15:39:57 GMT
Subject: <AWT Dev> RFR: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
In-Reply-To: <7guSTOgWszoD8wmhD5j_yOfMl4SMhYLlKbdcAUWRnqI=.26e5165d-4592-4571-a9a8-403f1fc7b3d4@github.com>
References: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
 <7guSTOgWszoD8wmhD5j_yOfMl4SMhYLlKbdcAUWRnqI=.26e5165d-4592-4571-a9a8-403f1fc7b3d4@github.com>
Message-ID: <U762RZmX7-eRxqtQNVZ0nUYoX7di7nMMjN27bdlIIso=.9ac92d9e-b8d6-4815-84a7-2dd1711e58dc@github.com>

On Tue, 2 Feb 2021 07:13:03 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
>> in order to reduce the noise in the JDK17 CI.
>
> Marked as reviewed by pbansal (Reviewer).

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2344

From dcubed at openjdk.java.net  Tue Feb  2 15:39:58 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 2 Feb 2021 15:39:58 GMT
Subject: <AWT Dev> Integrated: 8260867: ProblemList
 java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
In-Reply-To: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
References: <qWqy1mMEeBHJodvtZYBh27M4OTAt0RLiZ4dcRmWPskY=.9790dd3e-e108-440e-84b3-5d5c8664ec89@github.com>
Message-ID: <gvZSgxUhd6vTRnVw3bbv-Rj8qcU8izVytk03w0Rgr4c=.588d35b5-a462-426c-80bb-a2c30acc817a@github.com>

On Mon, 1 Feb 2021 23:16:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux
> in order to reduce the noise in the JDK17 CI.

This pull request has now been integrated.

Changeset: defcb042
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/defcb042
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8260867: ProblemList java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java on linux

Reviewed-by: psadhukhan, jdv, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/2344

From kcr at openjdk.java.net  Tue Feb  2 21:21:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 2 Feb 2021 21:21:41 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
Message-ID: <7qWHYF0X8IH53kLeSOFGloWZfKI2DWjt4h8DWxqHecM=.7bc215b9-9c4b-4d5e-99cd-21bd9737daf5@github.com>

On Tue, 2 Feb 2021 00:30:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libosxapp/ThreadUtilities.m line 53:
>> 
>>> 51: @implementation ThreadUtilities
>>> 52: 
>>> 53: + (void)initialize {
>> 
>> I think we need to check how this new modes will work when the AWT is embedded inside SWT and FX.
>
> We are just specifying an additional run mode for JDK internal use.
> It means that when we are saying to process only events for that mode, then only those will be processed.
> And it is used only for nested event loops.
> Nothing eternal should be assuming AWT uses JNF at all, never mind in a particular way.
> 
> There is a special case for FX but I don't see a problem.
> 
> If you look at Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl
> there's a variable "inAWT".
>          isRunning = [[NSRunLoop currentRunLoop] runMode:(inAWT ? [JNFRunLoop javaRunLoopMode] : NSDefaultRunLoopMode) ... ]];
> 
> This is specified as
>         inAWT = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
>             @Override
>             public Boolean run() {
>                 return !Boolean.parseBoolean(System.getProperty("javafx.embed.singleThread", "false"));
>             }
>         });
>     }
> 
> So generally FX doesn't care, and is ignorant of this new mode.
> Unless you set that property to true, in which case AWT use the  NSDefaultRunLoopMode and so again FX is unaffected.
> Nothing in the FX sources goes anywhere near JNF .. or has a reference to the special mode.
> 
> Bottom line I don't see it being affected. 
> 
> I'll check with Kevin but also Gerard had a lot to do with the creation of the current FX toolkit.

I ran some tests embedding JavaFX into Swing and vice versa both with and without `-Djavafx.embed.singleThread=true` and I don't see any regression in behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From kcr at openjdk.java.net  Tue Feb  2 21:29:51 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 2 Feb 2021 21:29:51 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <NPMa9L7BQsZZDJ7XFLb9360ye-GOkN8fERMrWejNYvA=.549d405c-aa04-48ed-9c47-e6cf9f640600@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
 <jeQG24bC4F5ckJaMUCytdXBnXQNRrWG6GSJJ5ykH4RM=.a5aa45f2-f08c-4c3e-9e66-e61bda1017e5@github.com>
 <NPMa9L7BQsZZDJ7XFLb9360ye-GOkN8fERMrWejNYvA=.549d405c-aa04-48ed-9c47-e6cf9f640600@github.com>
Message-ID: <Z2rKYZ3KuBkjt8MemhmYOZ9HcJF6lgvVoRG808PVHVI=.ee3a3115-e4f5-41e3-90de-300bdf1257eb@github.com>

On Mon, 1 Feb 2021 18:33:32 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Marked as reviewed by gziemski (Committer).
>
> The changes look good to me, but please see my comment from my review about documenting `NormalizedPathNSStringFromJavaString()` API.

The following commit was integrated to jdk master since you created this branch:

acbcde8 : [JDK-8256111](https://bugs.openjdk.java.net/browse/JDK-8256111) : Create implementation for NSAccessibilityStaticText protocol

with a new reference to JNF, so it fails to compile with this patch. You will need to merge openjdk/jdk master into your PR branch and then fix the new JNF reference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From serb at openjdk.java.net  Tue Feb  2 22:11:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 2 Feb 2021 22:11:48 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <7qWHYF0X8IH53kLeSOFGloWZfKI2DWjt4h8DWxqHecM=.7bc215b9-9c4b-4d5e-99cd-21bd9737daf5@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
 <7qWHYF0X8IH53kLeSOFGloWZfKI2DWjt4h8DWxqHecM=.7bc215b9-9c4b-4d5e-99cd-21bd9737daf5@github.com>
Message-ID: <GlA0aQIBFGbMEiw_mYj_Pf42iAAOGTXFqeO4O_4RhYw=.528e9a26-ea9b-42b4-ae88-9290ba6e5a30@github.com>

On Tue, 2 Feb 2021 21:18:42 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> We are just specifying an additional run mode for JDK internal use.
>> It means that when we are saying to process only events for that mode, then only those will be processed.
>> And it is used only for nested event loops.
>> Nothing eternal should be assuming AWT uses JNF at all, never mind in a particular way.
>> 
>> There is a special case for FX but I don't see a problem.
>> 
>> If you look at Java_sun_lwawt_macosx_LWCToolkit_doAWTRunLoopImpl
>> there's a variable "inAWT".
>>          isRunning = [[NSRunLoop currentRunLoop] runMode:(inAWT ? [JNFRunLoop javaRunLoopMode] : NSDefaultRunLoopMode) ... ]];
>> 
>> This is specified as
>>         inAWT = AccessController.doPrivileged(new PrivilegedAction<Boolean>() {
>>             @Override
>>             public Boolean run() {
>>                 return !Boolean.parseBoolean(System.getProperty("javafx.embed.singleThread", "false"));
>>             }
>>         });
>>     }
>> 
>> So generally FX doesn't care, and is ignorant of this new mode.
>> Unless you set that property to true, in which case AWT use the  NSDefaultRunLoopMode and so again FX is unaffected.
>> Nothing in the FX sources goes anywhere near JNF .. or has a reference to the special mode.
>> 
>> Bottom line I don't see it being affected. 
>> 
>> I'll check with Kevin but also Gerard had a lot to do with the creation of the current FX toolkit.
>
> I ran some tests embedding JavaFX into Swing and vice versa both with and without `-Djavafx.embed.singleThread=true` and I don't see any regression in behavior.

I am mostly worried about the usage of JNF by someone else's native code, as far as I understand it could be "broken" now. But it is good that FX does not use it.

BTW looks like all comments like  "// AWT_THREADING Safe (AWTRunLoop)" could be removed now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From serb at openjdk.java.net  Tue Feb  2 22:11:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 2 Feb 2021 22:11:48 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
Message-ID: <lRLoyazVxVWrRZ2EWrR4j5pSVPruURrQFL2GlxACIsk=.99cc7a10-e8d7-4b95-9192-94adadff3e55@github.com>

On Mon, 1 Feb 2021 23:47:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m line 611:
>> 
>>> 609:         const jchar *unichars = (*env)->GetStringChars(env, str, NULL);
>>> 610:         if (unichars == NULL) {
>>> 611:             return;
>> 
>> Do not we need to throw an exception here? Otherwise, GetStringChars error will be ignored?
>
> Look a few lines further up at my reply 3 days ago Gerard about this.

I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?

>> src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m line 967:
>> 
>>> 965: static NSNumber* JavaNumberToNSNumber(JNIEnv *env, jobject jnumber) {
>>> 966:     if (jnumber == NULL) {
>>> 967:         return nil;
>> 
>> Based on its usage it is probably should be zero on NULL number?
>
> Not an unreasonable idea and I considered it but :
> - It is never called with NULL. There is always a null check
> - The JNF equivalent returns nil on NULL
> 
> BTW two of the functions in which the code appears : accessibilityMinValueAttribute and accessibilityMaxValueAttribute  (SFAIC) aren't used anywhere.

@azuev-java Looks like a cleanup opportunity?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Tue Feb  2 22:31:47 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 22:31:47 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <GlA0aQIBFGbMEiw_mYj_Pf42iAAOGTXFqeO4O_4RhYw=.528e9a26-ea9b-42b4-ae88-9290ba6e5a30@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
 <7qWHYF0X8IH53kLeSOFGloWZfKI2DWjt4h8DWxqHecM=.7bc215b9-9c4b-4d5e-99cd-21bd9737daf5@github.com>
 <GlA0aQIBFGbMEiw_mYj_Pf42iAAOGTXFqeO4O_4RhYw=.528e9a26-ea9b-42b4-ae88-9290ba6e5a30@github.com>
Message-ID: <AIRF0TUiEKd3r1LB5QhEuW8KRPZ38G5gP2kM-1jYVIA=.a1f49b2a-d91c-4b27-a032-ad178c54524d@github.com>

On Tue, 2 Feb 2021 22:02:14 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I ran some tests embedding JavaFX into Swing and vice versa both with and without `-Djavafx.embed.singleThread=true` and I don't see any regression in behavior.
>
> I am mostly worried about the usage of JNF by someone else's native code, as far as I understand it could be "broken" now. But it is good that FX does not use it.
> 
> BTW looks like all comments like  "// AWT_THREADING Safe (AWTRunLoop)" could be removed now.

SWT does not use JNF at all. I've looked at their source code.
I can clean up those comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Tue Feb  2 22:35:41 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 22:35:41 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <lRLoyazVxVWrRZ2EWrR4j5pSVPruURrQFL2GlxACIsk=.99cc7a10-e8d7-4b95-9192-94adadff3e55@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
 <lRLoyazVxVWrRZ2EWrR4j5pSVPruURrQFL2GlxACIsk=.99cc7a10-e8d7-4b95-9192-94adadff3e55@github.com>
Message-ID: <kKNfpdCeggEbZteeIFfg8Z3JIDMWZpZf9Q8sHcMYqZ8=.fb350a0b-664a-4cd9-9a0d-1ab47ed1bbc9@github.com>

On Tue, 2 Feb 2021 21:48:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Look a few lines further up at my reply 3 days ago Gerard about this.
>
> I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?

> The changes look good to me, but please see my comment from my review about documenting `NormalizedPathNSStringFromJavaString()` API.

I see it. I will copy what you wrote in there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Tue Feb  2 22:42:51 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 22:42:51 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v3]
In-Reply-To: <kKNfpdCeggEbZteeIFfg8Z3JIDMWZpZf9Q8sHcMYqZ8=.fb350a0b-664a-4cd9-9a0d-1ab47ed1bbc9@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <5NHwdFUnJY6DIHDwzuoou_GuypUP_Upasu_LXGBraWU=.ec548e79-b248-4989-ba99-cd8811a6b5dc@github.com>
 <kvkrfQ8236S8JDOIiyiVVGcR3SIdIdrl-j7WffzbCbI=.d92bcbcc-7df0-41fe-8acc-b573367be21c@github.com>
 <XgWpvXVzQv39gdkv27x9fyEw60Q3fKdWyavqiHHQjSE=.8e3f7b32-8134-468b-8429-280b22a990c9@github.com>
 <lRLoyazVxVWrRZ2EWrR4j5pSVPruURrQFL2GlxACIsk=.99cc7a10-e8d7-4b95-9192-94adadff3e55@github.com>
 <kKNfpdCeggEbZteeIFfg8Z3JIDMWZpZf9Q8sHcMYqZ8=.fb350a0b-664a-4cd9-9a0d-1ab47ed1bbc9@github.com>
Message-ID: <qbxYIN2wZZbLemF3-p8FIATSGdNsIR5QkX70bu9gzqs=.f1f79b78-9132-43d1-80e8-3dc0dcaede64@github.com>

On Tue, 2 Feb 2021 22:33:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?
>
>> The changes look good to me, but please see my comment from my review about documenting `NormalizedPathNSStringFromJavaString()` API.
> 
> I see it. I will copy what you wrote in there.

> I read it and not sure that it is fine to ignore this error, why not throw an exception and signal the CTextPipe_doDrawString that an error occurred like InvalidPipeException or something(Sometimes we wrap other exception like OOM into the InvalidPipeException and this seems similar case)?

OK. I will do something like throw OOME or InternalError. Since we already checked for NULL as an arg any failure here implies a deep VM problem rather than anytjhing like a 2D invalid pipe

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From omikhaltcova at openjdk.java.net  Tue Feb  2 22:53:57 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Tue, 2 Feb 2021 22:53:57 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v2]
In-Reply-To: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
Message-ID: <r_29BJgyyg89MweV8NPnu88uwEdzGCblNRFZjbfZnuk=.a7dbfe78-c89c-4ab2-83f9-1a0b1569f306@github.com>

> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on!
> 
> This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H).
> 
> The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. 
> 
> Testing is quite complicated because for reproducing this bug the following conditions should be met:
> 1.	HiDPI is turned on
> 2.	sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100%
> 3.	the source of drag-n-drop is non-java application
> 
> The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414.

Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:

  8257414: Drag n Drop target area is wrong on high DPI systems

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1907/files
  - new: https://git.openjdk.java.net/jdk/pull/1907/files/ab3eb6a0..e4c1c73d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1907&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1907&range=00-01

  Stats: 43 lines in 1 file changed: 41 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1907/head:pull/1907

PR: https://git.openjdk.java.net/jdk/pull/1907

From prr at openjdk.java.net  Tue Feb  2 23:22:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 23:22:12 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v4]
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <H-iKmgjjtEV2kjC8jFxZUySdwkJmhJcUk1xLE8sgoDo=.d181c160-c47c-4705-8427-33416991979f@github.com>

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - Merge branch 'master' into jnf_string
 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - 8260616: Removing remaining JNF dependencies in the java.desktop modul
 - 8260616: Removing remaining JNF dependencies in the java.desktop module

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2305/files
  - new: https://git.openjdk.java.net/jdk/pull/2305/files/7ea57c85..8a014fa6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=02-03

  Stats: 34374 lines in 817 files changed: 13984 ins; 9392 del; 10998 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Tue Feb  2 23:22:12 2021
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 2 Feb 2021 23:22:12 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v2]
In-Reply-To: <Z2rKYZ3KuBkjt8MemhmYOZ9HcJF6lgvVoRG808PVHVI=.ee3a3115-e4f5-41e3-90de-300bdf1257eb@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <yyXcEb1t238Ikl36CGQ4ic_Z0N5l5tge4UmA6ifmbBM=.e7ca5367-9087-4088-b600-fce9133f6e53@github.com>
 <jeQG24bC4F5ckJaMUCytdXBnXQNRrWG6GSJJ5ykH4RM=.a5aa45f2-f08c-4c3e-9e66-e61bda1017e5@github.com>
 <NPMa9L7BQsZZDJ7XFLb9360ye-GOkN8fERMrWejNYvA=.549d405c-aa04-48ed-9c47-e6cf9f640600@github.com>
 <Z2rKYZ3KuBkjt8MemhmYOZ9HcJF6lgvVoRG808PVHVI=.ee3a3115-e4f5-41e3-90de-300bdf1257eb@github.com>
Message-ID: <EYPQNyzIET8bfWKnIJyzs5phrhpGmD_73Ut7ZT3--ho=.296158af-3c0c-4e97-945c-866cecdcd9c1@github.com>

On Tue, 2 Feb 2021 21:26:28 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> The changes look good to me, but please see my comment from my review about documenting `NormalizedPathNSStringFromJavaString()` API.
>
> The following commit was integrated to jdk master since you created this branch:
> 
> acbcde8 : [JDK-8256111](https://bugs.openjdk.java.net/browse/JDK-8256111) : Create implementation for NSAccessibilityStaticText protocol
> 
> with a new reference to JNF, so it fails to compile with this patch. You will need to merge openjdk/jdk master into your PR branch and then fix the new JNF reference.

Updated as follows
- merged to current master and fixed the new A11Y usage of JNF
- added comment provided by Gerard
- removed comments as suggested by Sergey
- made failure of GetStringChars in CTextPipe throw OOME

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From omikhaltcova at openjdk.java.net  Tue Feb  2 23:43:39 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Tue, 2 Feb 2021 23:43:39 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v2]
In-Reply-To: <9aTI_kCtelWx7_23xauxA_81kXbsHoyun-AsNl8qf_8=.c7d54e1b-c274-498f-bea1-7c6acbeb9d4f@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
 <BF-2-e4Bovdh14ViwYjg0KFxq_XiexmphkyOHLVYpjs=.5db16f5f-44ff-4220-a289-8725d8025497@github.com>
 <zEVVlT5Ic9AAzfGoU4qIF_txDyW4TNspOs86aOhRsis=.4c1f53dc-220e-469f-a843-aedd43e2fda8@github.com>
 <81gphZwW6IcxQKRHJkvL-3OFSTELCi7qPX32WCKj7Qg=.21bbd517-5771-41bd-87a7-802a6e78b989@github.com>
 <w1knB6UboXxx88b__Z-1dhxky3Lgbhgxidle0Uqz58Q=.e24e575b-6226-4f40-a60e-1ed8f7245c88@github.com>
 <9aTI_kCtelWx7_23xauxA_81kXbsHoyun-AsNl8qf_8=.c7d54e1b-c274-498f-bea1-7c6acbeb9d4f@github.com>
Message-ID: <TuIu2KtBK5uyWK74McmPIANRr1o4ohmL1zt1rqbvseY=.3b7cbaf8-8c02-449f-9357-395d4b0922db@github.com>

On Wed, 20 Jan 2021 01:59:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I failed to test branches of XDnDDropTargetProtocol::processXdndPosition(..) under condition (xwindow == null) by means of EmbeddedFrame. In addition none of automatic regression tests (test/jdk/java/awt/dnd/, test/jdk/java/awt/xembed/, test/jdk/sun/awt) gets into these branches.
>> 
>> I also tried to scale coordinates (as you advised) right after:
>>         x = (int)(xclient.get_data(2) >> 16);
>>         y = (int)(xclient.get_data(2) & 0xFFFF);
>> as follow:        
>> GraphicsConfiguration gc = GraphicsEnvironment
>>                 .getLocalGraphicsEnvironment()
>>                 .getDefaultScreenDevice()
>>                 .getDefaultConfiguration();
>>         gc = SunGraphicsEnvironment.getGraphicsConfigurationAtPoint(gc, x, y);
>>         GraphicsDevice device = gc.getDevice();
>>         if (device instanceof X11GraphicsDevice) {
>>             int scale = ((X11GraphicsDevice) device).getScaleFactor();
>>             x = XlibUtil.scaleDown(x, scale);
>>             y = XlibUtil.scaleDown(y, scale);
>>         }
>> 
>> but found out that getGraphicsConfigurationAtPoint() also requires the already scaled coordinates.
>> 
>> There are 3 different places in XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to decide whether to scale coordinates or not:
>> 1) I'm not sure and I'm unable to test it:
>> if (xwindow == null)
>>         {
>>             long receiver =
>>                 XDropTargetRegistry.getRegistry().getEmbeddedDropSite(
>>                     xclient.get_window(), x, y);
>> 2) I'm quite sure and I'm able to test it:
>> if (xwindow != null) {
>>             /* Translate mouse position from root coordinates
>>                to the target window coordinates. */
>>             Point p = xwindow.toLocal(xwindow.scaleDown(x), xwindow.scaleDown(y));
>> 3) I think that scaling is necessary but I'm unable to test it (additionally the question raises concerning this case, why the coordinates are not converted to local here similar to the 2 case):
>> if (xwindow == null) {
>>             if (targetXWindow != null) {
>>                 notifyProtocolListener(targetXWindow, x, y,
>>                                        DnDConstants.ACTION_NONE, xclient,
>>                                        MouseEvent.MOUSE_EXITED);
>> 
>> Sergey, is it possible at the moment to fix the particular issue and leave the other use cases to work as it works before due to no possibility to test them?
>
>> There are 3 different places in XDnDDropTargetProtocol::processXdndPosition(..) where it is necessary to decide whether to scale coordinates or not:
> 
> Unfortunately, this is the purpose of the whole fix to decide when the scale is required and then not, otherwise we can simply break the untested cases.

Sergey, please, review my last changes! Finally I managed to check all necessary branches in XDnDDropTargetProtocol::processXdndPosition(..). The user's space (the scaled version of the device) must be used everywhere here. I had to devide scaling according to condition (xwindow != null) in order to use more simple and fast realization for most of cases. The scaling for the case (xwindow == null) related to the embedded frame is based on the idea that there is only one pointer (cursor) in the system and it is used for drag-n-drop operation. I tried different ways to get scale in the last case but only this one is workable. If you have some better idea, tell me, please, another way to do it!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1907

From serb at openjdk.java.net  Wed Feb  3 03:44:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Feb 2021 03:44:40 GMT
Subject: <AWT Dev> Integrated: 8076313: GraphicsEnvironment does not detect
 changes in count of monitors on Linux OS
In-Reply-To: <JhSf4DUgF9_Wc-_4u3t0pNXxdg-elLn8hr0VhOqkn8g=.07ea8917-7a72-40c5-a4b1-97240fcc0584@github.com>
References: <JhSf4DUgF9_Wc-_4u3t0pNXxdg-elLn8hr0VhOqkn8g=.07ea8917-7a72-40c5-a4b1-97240fcc0584@github.com>
Message-ID: <zZ5S0hSI7hJQQvIM3XsZjx8ldRRFFui4egRTQFSESow=.6c8ac193-2f00-4f01-a8b3-33716a76a4b9@github.com>

On Tue, 26 Jan 2021 04:08:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This fix enables display change detection on Linux when the number of monitors is changed in the Xinerama mode.
> 
> The fix itself is straightforward:
> 1. When we get an event that the root window is changed we assume that it could be caused by some screen manipulation like screen resolution change or adding/removing a monitor.
> 2. We rebuild the native data structure for the x11 screens, and then mirror this data on the java level in the X11GraphicsEnvironment.
> 3. While we updating the data, we block all access to it in the native -> after the fix all access to the native x11 screens should be done under awt-lock.
> 
> Notes:
>  - This fix has a long chain of pre-fixes where we dropped the native access to the x11 screens, to minimize the places we need to synchronize.
>  - In the current version we rebuild the screens more often than needed, for example, we rebuild it even if resolution changed in a single monitor config. It is done intentionally to increase the test code coverage for now.
>  - The current implementation is based on the Xinerama, while the better solution will be use XRandr 1.5, but it does not support AIX, and is not supported in the current devkit.

This pull request has now been integrated.

Changeset: 98a76921
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/98a76921
Stats:     345 lines in 6 files changed: 203 ins; 103 del; 39 mod

8076313: GraphicsEnvironment does not detect changes in count of monitors on Linux OS

Reviewed-by: kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/2230

From psadhukhan at openjdk.java.net  Wed Feb  3 12:15:56 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 3 Feb 2021 12:15:56 GMT
Subject: <AWT Dev> RFR: 6211257: BasicStroke.createStrokedShape(Shape): NPE
 is not specified
Message-ID: <Jz5OKqYJxEgNehw-fjzV6jnAXJh--gUfsx8HcYrbc1g=.b1c4c5c5-5076-4e72-a785-f7994ae1883c@github.com>

Method createStrokedShape(Shape) for java.awt.BasicStroke class throws NullPointerException when passed a null object reference for a input parameter but it's not specified in the spec.
Updated spec to illustrate this.

-------------

Commit messages:
 - 6211257: BasicStroke.createStrokedShape(Shape): NPE is not specified
 - 6211257: BasicStroke.createStrokedShape(Shape): NPE is not specified

Changes: https://git.openjdk.java.net/jdk/pull/2377/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2377&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6211257
  Stats: 47 lines in 2 files changed: 47 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2377.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2377/head:pull/2377

PR: https://git.openjdk.java.net/jdk/pull/2377

From kizune at openjdk.java.net  Wed Feb  3 18:55:57 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Feb 2021 18:55:57 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
Message-ID: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>

8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

-------------

Commit messages:
 - 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Changes: https://git.openjdk.java.net/jdk/pull/2384/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8216358
  Stats: 164 lines in 2 files changed: 162 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2384/head:pull/2384

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Wed Feb  3 19:13:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 3 Feb 2021 19:13:40 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <CIwm6HzyFop6R3B7gOYOv5-hhqzJ3oH1twzz-gDqWpo=.1b5035ff-0c99-4a0b-85c4-dd4a5e2f70df@github.com>

On Wed, 3 Feb 2021 18:50:34 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

This is how radio button group with custom icons looks without the fix. The focus is on the middle radio button.
<img width="332" alt="nofix" src="https://user-images.githubusercontent.com/69642324/106796383-1e5f3d00-6610-11eb-9e28-44927d2eed5c.png">
This is how the same widget looks with the fix. Presence of the focus is clearly visible.
<img width="327" alt="withfix" src="https://user-images.githubusercontent.com/69642324/106796565-62ead880-6610-11eb-9113-2e873375f44a.png">

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Wed Feb  3 23:54:56 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 3 Feb 2021 23:54:56 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>

On Wed, 3 Feb 2021 18:50:34 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:

> 66:     public void performTest() throws Exception {
> 67:         try {
> 68:             BufferedImage imageFocus1 = null;

Probably the usage of Robot/Frame could be removed? Could you try to create the buffered image and button then paint the button to the graphics via button.paint(Graphics)? I guess in this case you can check the content of the buffered image directly w/o the robot.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java line 178:

> 176:             }
> 177: 
> 178:             altIcon.paintIcon(c, g, iconRect.x - offset, iconRect.y - offset);

Is it possible that due to offset on the left/top we will draw the icon outside the button bounds on the right/bottom?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Thu Feb  4 01:12:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Feb 2021 01:12:41 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
In-Reply-To: <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>
Message-ID: <N2_zOpCXMyvrbArHIk8LvqKUKCDjvLbmB-0zvnqklJA=.805370a2-b391-4b43-afec-68a4b3f3b232@github.com>

On Wed, 3 Feb 2021 23:50:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
>
> test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:
> 
>> 66:     public void performTest() throws Exception {
>> 67:         try {
>> 68:             BufferedImage imageFocus1 = null;
> 
> Probably the usage of Robot/Frame could be removed? Could you try to create the buffered image and button then paint the button to the graphics via button.paint(Graphics)? I guess in this case you can check the content of the buffered image directly w/o the robot.

How it will work if the button was too small say w=4 pixels?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Thu Feb  4 01:19:48 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 4 Feb 2021 01:19:48 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v4]
In-Reply-To: <H-iKmgjjtEV2kjC8jFxZUySdwkJmhJcUk1xLE8sgoDo=.d181c160-c47c-4705-8427-33416991979f@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
 <H-iKmgjjtEV2kjC8jFxZUySdwkJmhJcUk1xLE8sgoDo=.d181c160-c47c-4705-8427-33416991979f@github.com>
Message-ID: <cFmiLaQuoHechKJFnypKBtMKFrKv9hvvg4IQCsrCvug=.4eab2949-a212-480b-a840-f3aa54df1741@github.com>

On Tue, 2 Feb 2021 23:22:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> This completes the desktop module JNF removal
>> 
>> * remove  -framework JavaNativeFoundation from make files
>> 
>> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
>> 
>> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
>> 
>> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
>> 
>> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
>> 
>> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
>> 
>> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
>> 
>> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
>> 
>> * Remove the single usage of JNFPerformEnvBlock
>> 
>> * replace JNFJavaToNSNumber in single A11Y file with local replacement
>> 
>> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
>> 
>> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
>> 
>> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)
>
> Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - 8260616: Removing remaining JNF dependencies in the java.desktop module
>  - 8260616: Removing remaining JNF dependencies in the java.desktop module
>  - Merge branch 'master' into jnf_string
>  - 8260616: Removing remaining JNF dependencies in the java.desktop module
>  - 8260616: Removing remaining JNF dependencies in the java.desktop modul
>  - 8260616: Removing remaining JNF dependencies in the java.desktop module

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Thu Feb  4 01:35:21 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 4 Feb 2021 01:35:21 GMT
Subject: <AWT Dev> RFR: 8260616: Removing remaining JNF dependencies in
 the java.desktop module [v5]
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <hlMuA0SoOP27s3aP--F-KZN89PiQh6TbsDnZu4D4QMg=.4d52fb39-e980-46d0-a515-3ffe0ca9e834@github.com>

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into jnf_string
 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - Merge branch 'master' into jnf_string
 - 8260616: Removing remaining JNF dependencies in the java.desktop module
 - 8260616: Removing remaining JNF dependencies in the java.desktop modul
 - 8260616: Removing remaining JNF dependencies in the java.desktop module

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2305/files
  - new: https://git.openjdk.java.net/jdk/pull/2305/files/8a014fa6..43880e5f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2305&range=03-04

  Stats: 3151 lines in 249 files changed: 1263 ins; 952 del; 936 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2305/head:pull/2305

PR: https://git.openjdk.java.net/jdk/pull/2305

From prr at openjdk.java.net  Thu Feb  4 01:39:46 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 4 Feb 2021 01:39:46 GMT
Subject: <AWT Dev> Integrated: 8260616: Removing remaining JNF dependencies
 in the java.desktop module
In-Reply-To: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
References: <7gwXAtzyrQG0pZe95BvHWr3x2gkKBreaLV7KGzh2fNY=.bd74cc79-50fc-4e72-be14-ee8692ee535a@github.com>
Message-ID: <Ol-lAoBBCeW300UvBIA7aLcM4NEVsBpljYgbKCnzflM=.62621526-b9b8-4b84-9233-3fdc4d0bfb33@github.com>

On Fri, 29 Jan 2021 00:30:21 GMT, Phil Race <prr at openjdk.org> wrote:

> This completes the desktop module JNF removal
> 
> * remove  -framework JavaNativeFoundation from make files
> 
> * remove  #import <JavaNativeFoundation/JavaNativeFoundation.h> from all source files. If needed add import of JNIUtilities.h to get jni.h definitions - better anyway since then it gets the current JDK ones not the ones from the O/S
> 
> * replace JNFNSToJavaString with NSStringToJavaString and  JNFJavaToNSString with JavaStringToNSString
> 
> * replace JNFNormalizedNSStringForPath with NormalizedPathNSStringFromJavaString and JNFNormalizedJavaStringForPath with NormalizedPathJavaStringFromNSString
> 
> * replace JNFGet/ReleaseStringUTF16UniChars with direct calls to JNI
> 
> * Map all JNFRunLoop perform* calls to the ThreadUtilities versions (the vast majority already did this)
> 
> * Redo the ThreadUtilities calls to JNFRunLoop to directly invoke NSObject perform* methods.
> 
> * define new javaRunLoopMode in ThreadUtilities to replace the JNF one and use where needed.
> 
> * Remove the single usage of JNFPerformEnvBlock
> 
> * replace JNFJavaToNSNumber in single A11Y file with local replacement
> 
> * replace single usage of JNFNSTimeIntervalToJavaMillis in ScreenMenu.m with local replacement
> 
> * remove un-needed JNFRunLoopDidStartNotification from NSApplicationAWT.m
> 
> * misc. remaining cleanup (eg missed JNF_CHECK_AND_RETHROW_EXCEPTION)

This pull request has now been integrated.

Changeset: 8760688d
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8760688d
Stats:     580 lines in 74 files changed: 243 ins; 99 del; 238 mod

8260616: Removing remaining JNF dependencies in the java.desktop module

Reviewed-by: gziemski, ihse, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2305

From kizune at openjdk.java.net  Thu Feb  4 16:24:56 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 4 Feb 2021 16:24:56 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Test simplification.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2384/files
  - new: https://git.openjdk.java.net/jdk/pull/2384/files/95d09fa5..2b321845

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=00-01

  Stats: 98 lines in 1 file changed: 22 ins; 61 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2384/head:pull/2384

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Thu Feb  4 16:27:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 4 Feb 2021 16:27:40 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <N2_zOpCXMyvrbArHIk8LvqKUKCDjvLbmB-0zvnqklJA=.805370a2-b391-4b43-afec-68a4b3f3b232@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>
 <N2_zOpCXMyvrbArHIk8LvqKUKCDjvLbmB-0zvnqklJA=.805370a2-b391-4b43-afec-68a4b3f3b232@github.com>
Message-ID: <W2YW32GxHyDDoIGe19VRmk9reDTAVrl_3cdxSB3qOws=.73fb47f1-4074-4367-ad7a-b5571a619154@github.com>

On Thu, 4 Feb 2021 01:09:42 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:
>> 
>>> 66:     public void performTest() throws Exception {
>>> 67:         try {
>>> 68:             BufferedImage imageFocus1 = null;
>> 
>> Probably the usage of Robot/Frame could be removed? Could you try to create the buffered image and button then paint the button to the graphics via button.paint(Graphics)? I guess in this case you can check the content of the buffered image directly w/o the robot.
>
> How it will work if the button was too small say w=4 pixels?

1. Fixed.
2. If size of the icon based checkbox/radio button is less or equal than the icon size then the central part of the icon will be cropped and the halo will not be visible unless there are transparent pixels in the icon or icon is procedural and not paints on the whole icon area. We will not draw over other components in this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Thu Feb  4 16:31:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 4 Feb 2021 16:31:43 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <bo69Z1Wy0uWND88g4Np0JBhVqp5qfj6R3xgoOLMVpV0=.65ed758d-69f4-409f-94ba-3c6c25073b9b@github.com>
Message-ID: <ZSRgRQDwn8OPuNEP02leX46wDk1eWSRqoDtMKqKv6T8=.2e789861-53dd-4638-b067-1372b9ee2bfd@github.com>

On Wed, 3 Feb 2021 23:52:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test simplification.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonLabeledUI.java line 178:
> 
>> 176:             }
>> 177: 
>> 178:             altIcon.paintIcon(c, g, iconRect.x - offset, iconRect.y - offset);
> 
> Is it possible that due to offset on the left/top we will draw the icon outside the button bounds on the right/bottom?

No. I am substracting the offset to keep drawn image inside the checkbox/radiobutton icon drawing box which is by default size of the icon+4 in width and height, hence i am shifting it up and left to avoid drawing outside the icon box. If size of the image button is artificially limited to the value less or equal of the icon size then halo will be clipped to stay within the borders of the component. In any case we will not overdraw outside of the component.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From aghaisas at openjdk.java.net  Thu Feb  4 17:25:39 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 4 Feb 2021 17:25:39 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
Message-ID: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>

This is the implementation of JEP 382 : New macOS Rendering Pipeline (Metal rendering pipeline)

JEP Link - https://bugs.openjdk.java.net/browse/JDK-8238361

-------------

Commit messages:
 - Project Lanai Patch

Changes: https://git.openjdk.java.net/jdk/pull/2403/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260931
  Stats: 17445 lines in 83 files changed: 17395 ins; 1 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From ihse at openjdk.java.net  Thu Feb  4 20:48:42 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Feb 2021 20:48:42 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <1aQu91G1H0J3wMQmg_cwWWzw1w0BDKlvK5LDp1Mq0m4=.a0d452f9-1363-4a7c-adc0-98166b59db76@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Build changes look good. No opinion on the source changes.

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2403

From prr at openjdk.java.net  Fri Feb  5 01:31:52 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 5 Feb 2021 01:31:52 GMT
Subject: <AWT Dev> RFR: 8261198: [macOS] Incorrect JNI parameters in number
 conversion in A1Y code.
Message-ID: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>

we need to specify ()I for the signature of the method that returns int.
Additionally number (the instance!) needs to be passed to the method up call.

-------------

Commit messages:
 - 8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code

Changes: https://git.openjdk.java.net/jdk/pull/2418/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2418&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261198
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2418.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2418/head:pull/2418

PR: https://git.openjdk.java.net/jdk/pull/2418

From serb at openjdk.java.net  Fri Feb  5 02:20:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Feb 2021 02:20:42 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>
Message-ID: <JljJrLPJXhgPrQg1sQK7a96gbD2DNavVaHMS8KTxl34=.591a9792-5192-4f09-a04e-095be01f90be@github.com>

On Thu, 4 Feb 2021 16:24:56 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test simplification.

test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:

> 66:                 throw new Exception("Changing focus is not visualized");
> 67:             }
> 68:         } finally {

try/finally block is not needed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Fri Feb  5 02:26:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Feb 2021 02:26:40 GMT
Subject: <AWT Dev> RFR: 8261198: [macOS] Incorrect JNI parameters in
 number conversion in A1Y code.
In-Reply-To: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
References: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
Message-ID: <D4-66yQRlAbzpbM7UhosVH6SFOGCpHdXIQDi_MR2d8w=.52a250af-0117-40ff-bc12-3680a06398e0@github.com>

On Fri, 5 Feb 2021 01:27:26 GMT, Phil Race <prr at openjdk.org> wrote:

> we need to specify ()I for the signature of the method that returns int.
> Additionally number (the instance!) needs to be passed to the method up call.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2418

From kizune at openjdk.java.net  Fri Feb  5 05:09:04 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 5 Feb 2021 05:09:04 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <JljJrLPJXhgPrQg1sQK7a96gbD2DNavVaHMS8KTxl34=.591a9792-5192-4f09-a04e-095be01f90be@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>
 <JljJrLPJXhgPrQg1sQK7a96gbD2DNavVaHMS8KTxl34=.591a9792-5192-4f09-a04e-095be01f90be@github.com>
Message-ID: <9rX62PlA06c6XA9skyLi1HE39VaDlyqv6FwLmUOZlJM=.486f52c7-ec8d-404c-aaa1-225950d60fcb@github.com>

On Fri, 5 Feb 2021 02:17:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test simplification.
>
> test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:
> 
>> 66:                 throw new Exception("Changing focus is not visualized");
>> 67:             }
>> 68:         } finally {
> 
> try/finally block is not needed?

No, forgot to remove it. Not that it makes test invalid, but better get rid of it. Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Fri Feb  5 05:09:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 5 Feb 2021 05:09:03 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v3]
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <hwp_suoKU4-9_9C_vj2HBqcxc9KC67EeHxfCbpjC9sM=.7db9b0c4-32f4-4e60-8134-6932538c2a96@github.com>

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Removing unneeded try/catch block from the test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2384/files
  - new: https://git.openjdk.java.net/jdk/pull/2384/files/2b321845..20f24780

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=01-02

  Stats: 17 lines in 1 file changed: 0 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2384/head:pull/2384

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Fri Feb  5 05:12:00 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 5 Feb 2021 05:12:00 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v4]
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <KZRqn3-3l3FxPQbnF29EK7OAjSVjQ93IkSqfJ55MO_Q=.1a197571-a9c7-4cf8-9847-ac1df7f0c58f@github.com>

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Remove leftovers from last experiments.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2384/files
  - new: https://git.openjdk.java.net/jdk/pull/2384/files/20f24780..268fb774

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2384&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2384.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2384/head:pull/2384

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Fri Feb  5 05:26:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Feb 2021 05:26:40 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v4]
In-Reply-To: <KZRqn3-3l3FxPQbnF29EK7OAjSVjQ93IkSqfJ55MO_Q=.1a197571-a9c7-4cf8-9847-ac1df7f0c58f@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <KZRqn3-3l3FxPQbnF29EK7OAjSVjQ93IkSqfJ55MO_Q=.1a197571-a9c7-4cf8-9847-ac1df7f0c58f@github.com>
Message-ID: <o2PEpsGqbgx4opQMLGz2qJLVLiDwFnNvefg7sVllpac=.23e38b42-878b-47ea-a234-7730b1a90229@github.com>

On Fri, 5 Feb 2021 05:12:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove leftovers from last experiments.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From serb at openjdk.java.net  Fri Feb  5 05:29:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 5 Feb 2021 05:29:41 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <9rX62PlA06c6XA9skyLi1HE39VaDlyqv6FwLmUOZlJM=.486f52c7-ec8d-404c-aaa1-225950d60fcb@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>
 <JljJrLPJXhgPrQg1sQK7a96gbD2DNavVaHMS8KTxl34=.591a9792-5192-4f09-a04e-095be01f90be@github.com>
 <9rX62PlA06c6XA9skyLi1HE39VaDlyqv6FwLmUOZlJM=.486f52c7-ec8d-404c-aaa1-225950d60fcb@github.com>
Message-ID: <9NPXSD8AAW7V9U4MREs2re3IkufKH9Eujq5nDHSsNGM=.2337086c-d075-4672-9f96-eb59fd7bd839@github.com>

On Fri, 5 Feb 2021 05:06:23 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> test/jdk/javax/swing/JCheckBox/ImageCheckboxFocus/ImageCheckboxTest.java line 68:
>> 
>>> 66:                 throw new Exception("Changing focus is not visualized");
>>> 67:             }
>>> 68:         } finally {
>> 
>> try/finally block is not needed?
>
> No, forgot to remove it. Not that it makes test invalid, but better get rid of it. Fixed.

Looks fine, I assume that this test was checked via mach5 since the fix is in aqua and the test is cross-platform.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From kizune at openjdk.java.net  Fri Feb  5 05:58:41 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 5 Feb 2021 05:58:41 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v2]
In-Reply-To: <9NPXSD8AAW7V9U4MREs2re3IkufKH9Eujq5nDHSsNGM=.2337086c-d075-4672-9f96-eb59fd7bd839@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <oa1LZnME48Ga9WHbhE3saFrINomRECUUPrChnm4qdbI=.182bb74f-6239-40a8-b8f4-b46220497d61@github.com>
 <JljJrLPJXhgPrQg1sQK7a96gbD2DNavVaHMS8KTxl34=.591a9792-5192-4f09-a04e-095be01f90be@github.com>
 <9rX62PlA06c6XA9skyLi1HE39VaDlyqv6FwLmUOZlJM=.486f52c7-ec8d-404c-aaa1-225950d60fcb@github.com>
 <9NPXSD8AAW7V9U4MREs2re3IkufKH9Eujq5nDHSsNGM=.2337086c-d075-4672-9f96-eb59fd7bd839@github.com>
Message-ID: <lFGeU6pjrNSMuc2TrHzmJgq6YyVx4ek-1eKBgRECWT8=.2aea09b5-7fab-4ecb-a09f-56ec978ca4e0@github.com>

On Fri, 5 Feb 2021 05:26:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> No, forgot to remove it. Not that it makes test invalid, but better get rid of it. Fixed.
>
> Looks fine, I assume that this test was checked via mach5 since the fix is in aqua and the test is cross-platform.

Yes, did two separate runs - with and without actual fix applied. Fails without the fix on mac os x, passes with the fix on all platforms.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From pbansal at openjdk.java.net  Fri Feb  5 07:20:47 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 5 Feb 2021 07:20:47 GMT
Subject: <AWT Dev> RFR: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes" [v4]
In-Reply-To: <KZRqn3-3l3FxPQbnF29EK7OAjSVjQ93IkSqfJ55MO_Q=.1a197571-a9c7-4cf8-9847-ac1df7f0c58f@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
 <KZRqn3-3l3FxPQbnF29EK7OAjSVjQ93IkSqfJ55MO_Q=.1a197571-a9c7-4cf8-9847-ac1df7f0c58f@github.com>
Message-ID: <sKsk44iNj6VvxkELYgTqA6OANL6iyGLCcWU5Ntak9Ao=.9af6c10c-9b29-48eb-a8b2-eaf0d9562e3f@github.com>

On Fri, 5 Feb 2021 05:12:00 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove leftovers from last experiments.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From psadhukhan at openjdk.java.net  Fri Feb  5 11:44:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 5 Feb 2021 11:44:40 GMT
Subject: <AWT Dev> RFR: 8261198: [macOS] Incorrect JNI parameters in
 number conversion in A1Y code.
In-Reply-To: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
References: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
Message-ID: <50jwcQSAkMC7VIWaCoqNJ32XWqLD0OKFocTkXk9vA-c=.d6bf28cd-4d8a-4994-99df-98f2979c45c5@github.com>

On Fri, 5 Feb 2021 01:27:26 GMT, Phil Race <prr at openjdk.org> wrote:

> we need to specify ()I for the signature of the method that returns int.
> Additionally number (the instance!) needs to be passed to the method up call.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2418

From avu at openjdk.java.net  Fri Feb  5 17:57:41 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Fri, 5 Feb 2021 17:57:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <pqgCff4L2W2fYqsRUCsFmIbZK77u2jj7W7bkTHv_N3g=.e979cde9-c522-4e44-bf9c-c3819d8c0a9c@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Looks good except for one whitespace problem (src/java.desktop/share/native/libawt/java2d/SurfaceData.c)

src/java.desktop/share/native/libawt/java2d/SurfaceData.c line 238:

> 236: {
> 237:     SurfaceDataOps *ops = malloc(opsSize);
> 238: 

The only whitespace added. Should be removed

-------------

Changes requested by avu (no project role).

PR: https://git.openjdk.java.net/jdk/pull/2403

From prr at openjdk.java.net  Fri Feb  5 19:21:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 5 Feb 2021 19:21:39 GMT
Subject: <AWT Dev> Integrated: 8261198: [macOS] Incorrect JNI parameters in
 number conversion in A11Y code
In-Reply-To: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
References: <g797_ucmJ_HVLo_qqpFtOiyCceprcQ1aj33-gTuiOCE=.c26964e6-9442-4390-8a2d-d1179bc7ecda@github.com>
Message-ID: <cXbvm0UKi5HB-cSTmaAoXn3zbwLkyL9NyZnevhO5vTw=.55df3770-7d59-4a0b-ab69-3046501491cc@github.com>

On Fri, 5 Feb 2021 01:27:26 GMT, Phil Race <prr at openjdk.org> wrote:

> we need to specify ()I for the signature of the method that returns int.
> Additionally number (the instance!) needs to be passed to the method up call.

This pull request has now been integrated.

Changeset: 4a89733e
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4a89733e
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8261198: [macOS] Incorrect JNI parameters in number conversion in A11Y code

Reviewed-by: serb, psadhukhan

-------------

PR: https://git.openjdk.java.net/jdk/pull/2418

From kcr at openjdk.java.net  Fri Feb  5 20:22:49 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 5 Feb 2021 20:22:49 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <026mUCt0l4yG3PQpIAOaI8yTKXuhZ5M7iEtYUevF-yM=.2a0f903a-31e4-4dce-bd7c-4dd76be77f1b@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Here is my initial set of mostly minor comments and a couple questions.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.h line 33:

> 31: #import "common.h"
> 32: 
> 33: #import <JavaNativeFoundation/JavaNativeFoundation.h>

JNF has been removed from the jdk, so this must be removed or it will no longer compile. It has already been fixed in the lanai repo by [JDK-8261234](https://bugs.openjdk.java.net/browse/JDK-8261234).

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 38:

> 36: #import <string.h>
> 37: #import <ApplicationServices/ApplicationServices.h>
> 38: #import <JavaNativeFoundation/JavaNativeFoundation.h>

JNF has been removed from the jdk, so this must be removed or it will no longer compile. It has already been fixed in the lanai repo by [JDK-8261234](https://bugs.openjdk.java.net/browse/JDK-8261234).

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894:

> 892:   SHADERS_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui
> 893:   SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air
> 894:   SHADERS_LIB := $(INSTALL_LIBRARIES_HERE)/shaders.metallib

Q: Should 2d (or awt) be in the name of this file, or is a generic name OK?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Oracle and/or its affiliates. All rights reserved.

Should be `2019, 2021,` (I missed this file when I fixed up the copyright notices and years).

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 81:

> 79:             (PrivilegedAction<String>) () ->
> 80:                     System.getProperty("java.home", "") + File.separator +
> 81:                             "lib" + File.separator + "shaders.metallib");

Same question as in the makefile about the name of the shader library file.

src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 155:

> 153:             if (cfginfo != 0L) {
> 154:                 textureSize = nativeGetMaxTextureSize();
> 155:                 // 7160609: GL still fails to create a square texture of this

This refers to GL. Is this relevant to metal?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 78:

> 76:      * of the MTL pipeline and related classes.
> 77:      */
> 78:     public static void sync() {

Should this be synchronized?

src/java.desktop/macosx/classes/sun/java2d/opengl/CGLGraphicsConfig.java line 142:

> 140:                 // TODO : This clamping code is same as in OpenGL.
> 141:                 // Whether we need such clamping or not in case of Metal
> 142:                 // will be pursued under 8260644

This change seems wrong. The comment suggests it belong in a metal class or method, not here where we are using OpenGL.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CPlatformView.java line 193:

> 191:             responder.handleScrollEvent(x, y, absX, absY, event.getModifierFlags(),
> 192:                     event.getScrollDeltaX(), event.getScrollDeltaY(),
> 193:                     event.getScrollPhase());

Minor: This part of the file is otherwise unchanged. Maybe revert this whitespace-only change? Same applies to the last two changes in this file.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CWarningWindow.java line 227:

> 225:                             CWrapper.NSWindow.orderWindow(ptr,
> 226:                                     CWrapper.NSWindow.NSWindowAbove,
> 227:                                     ownerPtr);

Minor: This part of the file is otherwise unchanged. Maybe revert this whitespace-only change? Same applies futher down in a couple places.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.h line 47:

> 45:  *  2. Updates 'mutable' properties encoder: pipelineState (with corresponding buffers), clip, transform, e.t.c. To avoid
> 46:  *  unnecessary calls of [encoder setXXX] this manager compares requested state with cached one.
> 47:  * */

Minor: `* */` --> `*/`

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/EncoderManager.m line 204:

> 202: {
> 203:     if (clip.stencilMaskGenerationInProgress == JNI_TRUE) {
> 204:         // don't set setScissorOrStencil when generateion in progress

Minor: typo in comment, should be `generation`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kizune at openjdk.java.net  Fri Feb  5 22:30:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Fri, 5 Feb 2021 22:30:43 GMT
Subject: <AWT Dev> Integrated: 8216358: [accessibility] [macos] The focus is
 invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"
In-Reply-To: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
References: <BcFNBFNCsziIXQOmLRW8Q62vyRGPjnNHBUz9zYjyzr8=.d4e2b893-60ae-4ba7-9838-461bbab2d79e@github.com>
Message-ID: <UPNlk7UViDcw7YQ_-I5CwoJII-McWY2zC7OiOI45qUE=.b0e75c09-a6c8-4aa3-808c-b962e53d50c3@github.com>

On Wed, 3 Feb 2021 18:50:34 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

This pull request has now been integrated.

Changeset: 440db35e
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/440db35e
Stats:     117 lines in 2 files changed: 115 ins; 0 del; 2 mod

8216358: [accessibility] [macos] The focus is invisible when tab to "Image Radio Buttons" and "Image CheckBoxes"

Reviewed-by: serb, pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/2384

From kcr at openjdk.java.net  Fri Feb  5 23:07:43 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 5 Feb 2021 23:07:43 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

I left a few additional comments. Overall this looks good to me.

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 82:

> 80:     (JNIEnv *env, jclass mtlgc)
> 81: {
> 82:     FILE *f = popen("/usr/sbin/system_profiler SPDisplaysDataType", "r");

How robust is this? It seems like the contents of this could be an implementation detail and subject to change. Is it documented by Apple?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 83:

> 81: {
> 82:     FILE *f = popen("/usr/sbin/system_profiler SPDisplaysDataType", "r");
> 83:     bool metalSupported = JNI_FALSE;

This code is mixing types; it should be `jboolean metalSupported`

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLMaskFill.m line 26:

> 24:  */
> 25: 
> 26: #ifndef HEADLESS

I see a few occurrences of `#ifndef HEADLESS` in the metal pipeline. Is this needed? I don't see any of the other native macos files in Java2D (e.g., the OpenGL pipeline) doing the same. Will this file ever be compiled with HEADLESS being undefined?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLPaints.h line 41:

> 39: /**
> 40:  * The MTLPaint class represents paint mode (color, gradient, e.t.c.)
> 41:  * */

Minor: `* */` --> `*/`; also typo: `e.t.c.` should be `etc.`

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLSurfaceDataBase.h line 37:

> 35: 
> 36: /**
> 37:  * The MTLSDOps structure describes a native OpenGL surface and contains all

Should that be "Metal" and not "OpenGL" ?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTextRenderer.m line 77:

> 75:  * be safe to use this one glyph cache for all screens in a multimon
> 76:  * environment, since the glyph cache texture is shared between all contexts,
> 77:  * and (in theory) OpenGL drivers should be smart enough to manage that

`Metal` drivers?

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 29:

> 27: #import "Trace.h"
> 28: 
> 29: #define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb

This means that a 4k display with a narrower aspect ratio wouldn't fit (assuming there ever were to be such a thing). What would happen if you encountered a screen that was, say, 4k * 2.5K?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kcr at openjdk.java.net  Sat Feb  6 00:55:40 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 6 Feb 2021 00:55:40 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <qfbhy2F3tQWlhshIDoJiQyH0CHVrio8HEF-hyJyYGAw=.ae3d6fed-e70d-4e34-9a24-97891b6a1586@github.com>

On Thu, 4 Feb 2021 10:35:02 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

The file in `RenderPerfTest` should have a GPLv2 license header (no Classpath). I filed [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also highlighted a couple examples below.

test/jdk/performance/client/RenderPerfTest/Makefile line 10:

> 8: #   - Redistributions of source code must retain the above copyright
> 9: #     notice, this list of conditions and the following disclaimer.
> 10: #

As mentioned in the preliminary review, this file and `build.xml` have a BSD copyright. I think that should be GPLv2 (without classpath exception since this is a test).

test/jdk/performance/client/RenderPerfTest/src/renderperf/RenderPerfTest.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Since this a test, this should not have the Classpath exception.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From serb at openjdk.java.net  Sat Feb  6 02:35:43 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Feb 2021 02:35:43 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v2]
In-Reply-To: <r_29BJgyyg89MweV8NPnu88uwEdzGCblNRFZjbfZnuk=.a7dbfe78-c89c-4ab2-83f9-1a0b1569f306@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
 <r_29BJgyyg89MweV8NPnu88uwEdzGCblNRFZjbfZnuk=.a7dbfe78-c89c-4ab2-83f9-1a0b1569f306@github.com>
Message-ID: <y08RKlQcqHLRrERSQLmJ05dQS2SqKXFJN8mclidulAE=.83938572-9f2b-44ff-84da-24e0be1c146c@github.com>

On Tue, 2 Feb 2021 22:53:57 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on!
>> 
>> This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H).
>> 
>> The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. 
>> 
>> Testing is quite complicated because for reproducing this bug the following conditions should be met:
>> 1.	HiDPI is turned on
>> 2.	sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100%
>> 3.	the source of drag-n-drop is non-java application
>> 
>> The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257414: Drag n Drop target area is wrong on high DPI systems

src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 618:

> 616:             try {
> 617:                 for (int i = 0; i < gdslen; i++) {
> 618:                     long screenRoot = XlibWrapper.RootWindow(display, i);

I am not sure this will work in the multi-monitors configuration when the screen is split across a few monitors(when Xinerama is enabled for example). In such a configuration, only one root window and only one X11 screen exist. And the index of the GraphicsDevice is the index of the "virtual" monitor, so you cannot pass this index to the "XlibWrapper.RootWindow".

A few questions:
* Are you sure that to scale the x/y in the device space you need to find where the pointer is located? And not where the x/y coordinates are located themselves?
* Did you try to iterate over the devices->downscale the bounds of each GD to the device scale and upscale the x/y using the selected device. Such utility method can be added to the SunGraphicsEnvironment

-------------

PR: https://git.openjdk.java.net/jdk/pull/1907

From dmarkov at openjdk.java.net  Sun Feb  7 08:34:53 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Sun, 7 Feb 2021 08:34:53 GMT
Subject: <AWT Dev> RFR: 8261231: Windows IME was disabled after DnD operation
Message-ID: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>

The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage().

Fix:
SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.

-------------

Commit messages:
 - 8261231: Windows IME was disabled after DnD operation

Changes: https://git.openjdk.java.net/jdk/pull/2448/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2448&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261231
  Stats: 5 lines in 1 file changed: 3 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2448.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2448/head:pull/2448

PR: https://git.openjdk.java.net/jdk/pull/2448

From aghaisas at openjdk.java.net  Mon Feb  8 05:07:08 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 8 Feb 2021 05:07:08 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v2]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <v69AfGv23sUEkWAcW4YNZoVslOtHXwWZ-HD64pHB7nk=.09c4c2dd-656f-4cc2-a2eb-40345182f460@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Lanai PR#174 - 8261234 - kcr
 - Merge branch 'master' into 8260931_lanai_JEP_branch
   Merge from openjdk/jdk
 - Project Lanai Patch

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/0b8d96b2..8ed7b5f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=00-01

  Stats: 12194 lines in 245 files changed: 7103 ins; 4454 del; 637 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Mon Feb  8 12:28:07 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 8 Feb 2021 12:28:07 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:

  Lanai PR#175 - 8261304 - aghaisas

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/8ed7b5f5..6044adc0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=01-02

  Stats: 32 lines in 10 files changed: 0 ins; 12 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Mon Feb  8 13:42:41 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 8 Feb 2021 13:42:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <026mUCt0l4yG3PQpIAOaI8yTKXuhZ5M7iEtYUevF-yM=.2a0f903a-31e4-4dce-bd7c-4dd76be77f1b@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <026mUCt0l4yG3PQpIAOaI8yTKXuhZ5M7iEtYUevF-yM=.2a0f903a-31e4-4dce-bd7c-4dd76be77f1b@github.com>
Message-ID: <1B1HMTCLZYlhhHBKTI8Phtg85X6LG_HJWtXCHFcHStk=.84e2dc10-0052-4c92-8296-4992329dba95@github.com>

On Fri, 5 Feb 2021 18:42:02 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lanai PR#175 - 8261304 - aghaisas
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894:
> 
>> 892:   SHADERS_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui
>> 893:   SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air
>> 894:   SHADERS_LIB := $(INSTALL_LIBRARIES_HERE)/shaders.metallib
> 
> Q: Should 2d (or awt) be in the name of this file, or is a generic name OK?

I think, a generic name is OK as the path of shader file already has both awt (libawt_lwawt) and java2d in it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kcr at openjdk.java.net  Mon Feb  8 14:25:50 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 8 Feb 2021 14:25:50 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <1B1HMTCLZYlhhHBKTI8Phtg85X6LG_HJWtXCHFcHStk=.84e2dc10-0052-4c92-8296-4992329dba95@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <026mUCt0l4yG3PQpIAOaI8yTKXuhZ5M7iEtYUevF-yM=.2a0f903a-31e4-4dce-bd7c-4dd76be77f1b@github.com>
 <1B1HMTCLZYlhhHBKTI8Phtg85X6LG_HJWtXCHFcHStk=.84e2dc10-0052-4c92-8296-4992329dba95@github.com>
Message-ID: <dXrkAzyW6Zq4W3IXyuWCQ0IFYhL0iNyFI_KHmqWeA8o=.986014a8-5f71-4879-b470-abf1558cefe9@github.com>

On Mon, 8 Feb 2021 13:40:22 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 894:
>> 
>>> 892:   SHADERS_SUPPORT_DIR := $(SUPPORT_OUTPUTDIR)/native/java.desktop/libosxui
>>> 893:   SHADERS_AIR := $(SHADERS_SUPPORT_DIR)/shaders.air
>>> 894:   SHADERS_LIB := $(INSTALL_LIBRARIES_HERE)/shaders.metallib
>> 
>> Q: Should 2d (or awt) be in the name of this file, or is a generic name OK?
>
> I think, a generic name is OK as the path of shader file already has both awt (libawt_lwawt) and java2d in it.

In the source tree, yes, but not in the jdk image where it ends up in `$JAVA_HOME/lib/shaders.metallib`. I don't have a problem with this, as long as it is a deliberate decision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kizune at openjdk.java.net  Mon Feb  8 16:53:42 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Feb 2021 16:53:42 GMT
Subject: <AWT Dev> RFR: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
References: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
Message-ID: <l8Kyz7RRlTqYleX99JjlG2Of5ps-mnf28L80t-97HlM=.45ce5f61-e9af-4d6b-92df-035385f7528d@github.com>

On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage().
> 
> Fix:
> SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.

Change looks good and i haven't found any side-effects during testing. Could you please add the label to the bug noting reason for absence of the regression test, like noreg-hard or something?

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2448

From itakiguchi at openjdk.java.net  Mon Feb  8 16:56:42 2021
From: itakiguchi at openjdk.java.net (Ichiroh Takiguchi)
Date: Mon, 8 Feb 2021 16:56:42 GMT
Subject: <AWT Dev> RFR: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <l8Kyz7RRlTqYleX99JjlG2Of5ps-mnf28L80t-97HlM=.45ce5f61-e9af-4d6b-92df-035385f7528d@github.com>
References: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
 <l8Kyz7RRlTqYleX99JjlG2Of5ps-mnf28L80t-97HlM=.45ce5f61-e9af-4d6b-92df-035385f7528d@github.com>
Message-ID: <Rlg10R4VsHzZBFxKkaxmdad-bwEN-ql-DVI0yCAoGzA=.7c219c02-6002-4472-8dc6-4cc054c9580c@github.com>

On Mon, 8 Feb 2021 16:51:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage().
>> 
>> Fix:
>> SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.
>
> Change looks good and i haven't found any side-effects during testing. Could you please add the label to the bug noting reason for absence of the regression test, like noreg-hard or something?

I also tested this fix. It worked fine. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2448

From serb at openjdk.java.net  Mon Feb  8 17:04:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Feb 2021 17:04:40 GMT
Subject: <AWT Dev> RFR: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
References: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
Message-ID: <GAAraxMOzcpSWcXowCG1BT3ceDCP5lay20JVu3idWTI=.9f0421c7-ef49-428c-8e31-bd70cd89c977@github.com>

On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage().
> 
> Fix:
> SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2448

From dmarkov at openjdk.java.net  Mon Feb  8 17:07:41 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Mon, 8 Feb 2021 17:07:41 GMT
Subject: <AWT Dev> RFR: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <l8Kyz7RRlTqYleX99JjlG2Of5ps-mnf28L80t-97HlM=.45ce5f61-e9af-4d6b-92df-035385f7528d@github.com>
References: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
 <l8Kyz7RRlTqYleX99JjlG2Of5ps-mnf28L80t-97HlM=.45ce5f61-e9af-4d6b-92df-035385f7528d@github.com>
Message-ID: <MnKTkJKTYrzehVyRs3SP9T-FgyC2-r3E4z7xRyEno5I=.9a7b89ad-f978-4865-88a5-5a40bed6cb9b@github.com>

On Mon, 8 Feb 2021 16:51:21 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Change looks good and i haven't found any side-effects during testing. Could you please add the label to the bug noting reason for absence of the regression test, like noreg-hard or something?

Thank you for the review. I have added noreg-hard to the bug

-------------

PR: https://git.openjdk.java.net/jdk/pull/2448

From dmarkov at openjdk.java.net  Mon Feb  8 17:12:44 2021
From: dmarkov at openjdk.java.net (Dmitry Markov)
Date: Mon, 8 Feb 2021 17:12:44 GMT
Subject: <AWT Dev> Integrated: 8261231: Windows IME was disabled after DnD
 operation
In-Reply-To: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
References: <hnr0ZaJAdObU5NaC-YAT1nTU2mOY3iUtnJDaNC5U1Mo=.a9671166-e330-41ef-a207-5aa14fb8ab45@github.com>
Message-ID: <BpaZ7IouaSoTTQi7ALXd2m2Q_-bG-pII1VXG_1uTLBA=.ddc637e2-b045-484b-a91d-bf714fda5300@github.com>

On Sun, 7 Feb 2021 08:29:57 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> The function InvokeInputMethodFunction() is responsible for invocation of IME API. Typically it uses PostMessage() to execute corresponding IME function on the toolkit thread but if DnD operation takes place SendMessage() is used. The state of m_inputMethodWaitEvent event object remains signalled after SendMessage() execution. That causes failure of subsequent IME functions calls via PostMessage().
> 
> Fix:
> SendMessage() and PostMessage() calls inside InvokeInputMethodFunction() should be synchronised. The state of m_inputMethodWaitEvent event object must be reseted right after SendMessage() execution.

This pull request has now been integrated.

Changeset: d6d5d9bf
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6d5d9bf
Stats:     5 lines in 1 file changed: 3 ins; 1 del; 1 mod

8261231: Windows IME was disabled after DnD operation

Reviewed-by: kizune, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2448

From gziemski at openjdk.java.net  Mon Feb  8 17:18:42 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 8 Feb 2021 17:18:42 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <qfbhy2F3tQWlhshIDoJiQyH0CHVrio8HEF-hyJyYGAw=.ae3d6fed-e70d-4e34-9a24-97891b6a1586@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <qfbhy2F3tQWlhshIDoJiQyH0CHVrio8HEF-hyJyYGAw=.ae3d6fed-e70d-4e34-9a24-97891b6a1586@github.com>
Message-ID: <WKmXX-jmm1ddTCYUl48CbOQUhKoOPklg-3mUzcp5cus=.f4a52de1-e21c-4e74-8f31-1d207ccc065d@github.com>

On Sat, 6 Feb 2021 00:53:08 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lanai PR#175 - 8261304 - aghaisas
>
> The file in `RenderPerfTest` should have a GPLv2 license header (no Classpath). I filed [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also highlighted a couple examples below.

General comment - I am not sure I like the `MTL` prefix acronym in names (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`).

I think you tried to match the `CGL`, but that is a real acronym that stands for "Core Graphics Layer" (I think).

`MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I suppose, but also just `Metal` would work just fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Mon Feb  8 17:26:43 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 8 Feb 2021 17:26:43 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <WKmXX-jmm1ddTCYUl48CbOQUhKoOPklg-3mUzcp5cus=.f4a52de1-e21c-4e74-8f31-1d207ccc065d@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <qfbhy2F3tQWlhshIDoJiQyH0CHVrio8HEF-hyJyYGAw=.ae3d6fed-e70d-4e34-9a24-97891b6a1586@github.com>
 <WKmXX-jmm1ddTCYUl48CbOQUhKoOPklg-3mUzcp5cus=.f4a52de1-e21c-4e74-8f31-1d207ccc065d@github.com>
Message-ID: <uFB0FYVvU8EvG7_uUUZNzQ1U1Ih71Zwd4bjUzC1gInY=.353e7c70-dbf6-496d-9873-03d324ca17f1@github.com>

On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> The file in `RenderPerfTest` should have a GPLv2 license header (no Classpath). I filed [JDK-8261273](https://bugs.openjdk.java.net/browse/JDK-8261273) and also highlighted a couple examples below.
>
> General comment - I am not sure I like the `MTL` prefix acronym in names (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`).
> 
> I think you tried to match the `CGL`, but that is a real acronym that stands for "Core Graphics Layer" (I think).
> 
> `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I suppose, but also just `Metal` would work just fine.

I'm in the process of reviewing this feature, but there is lots of code to go through - please wait for my review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kcr at openjdk.java.net  Mon Feb  8 17:50:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 8 Feb 2021 17:50:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <WKmXX-jmm1ddTCYUl48CbOQUhKoOPklg-3mUzcp5cus=.f4a52de1-e21c-4e74-8f31-1d207ccc065d@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <qfbhy2F3tQWlhshIDoJiQyH0CHVrio8HEF-hyJyYGAw=.ae3d6fed-e70d-4e34-9a24-97891b6a1586@github.com>
 <WKmXX-jmm1ddTCYUl48CbOQUhKoOPklg-3mUzcp5cus=.f4a52de1-e21c-4e74-8f31-1d207ccc065d@github.com>
Message-ID: <wj8vh3MCEjsdHSlmK-hJpaVKhQVvkCxELJgeLrSPk0Q=.cf764cdf-b7c4-47e0-be3b-ce556f4d24a2@github.com>

On Mon, 8 Feb 2021 17:15:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> General comment - I am not sure I like the `MTL` prefix acronym in names (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`).
> 
> I think you tried to match the `CGL`, but that is a real acronym that stands for "Core Graphics Layer" (I think).
> 
> `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I suppose, but also just `Metal` would work just fine.

`MTL` is the abbreviation that Apple uses for Metal in all of their APIs. The only potential issue I might see with this prefix is in the native code where there could be name collisions between Java2D's names and Apple's names. Since we haven't run into such a collision, I don't think this needs to change, and wouldn't necessarily affect the Java class names anyway. If we were to consider it, `METAL` seems better than `ML` (which is too short to be descriptive and might suggest machine learning).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Mon Feb  8 18:12:48 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 8 Feb 2021 18:12:48 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
Message-ID: <rhOSngQoeE4RMbUdweZdQDVezQShNe-ucJ56FMcXszY=.6ba5b170-6d42-46a5-a3c1-c1ecfe6781af@github.com>

On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lanai PR#175 - 8261304 - aghaisas

> > General comment - I am not sure I like the `MTL` prefix acronym in names (ex. `sun.java2d.metal.MTLVolatileSurfaceManager`).
> > I think you tried to match the `CGL`, but that is a real acronym that stands for "Core Graphics Layer" (I think).
> > `MTL` on the other hand is no acronym. I can see `ML` for "Metal Layer" I suppose, but also just `Metal` would work just fine.
> 
> `MTL` is the abbreviation that Apple uses for Metal in all of their APIs. The only potential issue I might see with this prefix is in the native code where there could be name collisions between Java2D's names and Apple's names. Since we haven't run into such a collision, I don't think this needs to change, and wouldn't necessarily affect the Java class names anyway. If we were to consider it, `METAL` seems better than `ML` (which is too short to be descriptive and might suggest machine learning).

If Apple itself uses `MTL` then we are good.

src/java.desktop/macosx/classes/sun/awt/CGraphicsConfig.java line 35:

> 33: 
> 34: import sun.java2d.SurfaceData;
> 35: import sun.java2d.opengl.CGLLayer;

Not needed import anymore?

src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 113:

> 111:             // This indicates fallback to other rendering pipeline also failed.
> 112:             // Should never reach here
> 113:             throw new InternalError("Error - unable to initialize any rendering pipeline.");

There is no software based renderer to fall back here?

src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 66:

> 64:                        propString.equals("f") ||
> 65:                        propString.equals("False") ||
> 66:                        propString.equals("F"))

Shouldn't `1` and `0` be also allowed here?

src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 100:

> 98:                         oglState = PropertyState.ENABLED; // Enable default pipeline
> 99:                         metalState = PropertyState.DISABLED; // Disable non-default pipeline
> 100:                     }

This matches JEP 382 specification, but even when both GL is `false` and Metal is `false` we still get GL? There is no software based pipeline anymore?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 131:

> 129:         @Native
> 130:         static final int CAPS_EXT_GRAD_SHADER  = (FIRST_PRIVATE_CAP << 3);
> 131:         /** Indicates the presence of the GL_ARB_texture_rectangle extension. */

Reference to `GL_ARB_texture_rectangle` extension in Metal pipeline?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLContext.java line 134:

> 132:         @Native
> 133:         static final int CAPS_EXT_TEXRECT      = (FIRST_PRIVATE_CAP << 4);
> 134:         /** Indicates the presence of the GL_NV_texture_barrier extension. */

Reference to `GL_NV_texture_barrier` extension in Metal pipeline?

src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 97:

> 95:     public static void disposeGraphicsConfig(long pConfigInfo) {
> 96:         MTLRenderQueue rq = getInstance();
> 97:         rq.lock();

Is it allowed to have multiple `MTLRenderQueue` instances?

If not, then I see this pattern everywhere:

        MTLRenderQueue rq = getInstance();
        rq.lock();
        {
          ...
        }
        rq.unlock();
why not just do:

        MTLRenderQueue.lock();
        {
          ...
        }
        MTLRenderQueue.unlock();

and have `MTLRenderQueue.lock()` and `MTLRenderQueue.unlock()` implement getting the actual lock instance and locking/unlocking it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From serb at openjdk.java.net  Mon Feb  8 22:45:57 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 8 Feb 2021 22:45:57 GMT
Subject: <AWT Dev> RFR: 8261368: The new TestNullSetColor test is placed in
 the wrong group
Message-ID: <ACb_vI6tPHdmcsy6g9bb-JC6KpLttzic8l2PUyQ1xqo=.cf863ebf-ba13-4aaa-8ff6-d0efc007d9d5@github.com>

The test is moved to the "java/awt/Graphics/" since it validates behavior of the java.awt.Graphics$setColor() method.

-------------

Commit messages:
 - Update TestNullSetColor.java

Changes: https://git.openjdk.java.net/jdk/pull/2467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2467&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261368
  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2467/head:pull/2467

PR: https://git.openjdk.java.net/jdk/pull/2467

From gziemski at openjdk.java.net  Mon Feb  8 23:10:44 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 8 Feb 2021 23:10:44 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
Message-ID: <Tly92FYVx0I86iM4X-57Z2CSLi0ypaTJDMRmyD9OtCg=.3f7a2e8c-159e-404a-9356-ae7fc835c69b@github.com>

On Mon, 8 Feb 2021 12:28:07 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lanai PR#175 - 8261304 - aghaisas

Changes requested by gziemski (Committer).

src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 61:

> 59: 
> 60: public abstract class MTLSurfaceData extends SurfaceData
> 61:         implements AccelSurface {

`MTLSurfaceData` and `OGLSurfaceData` seem to share lots of the same code, isn't there a way to refactor the common code out?

There are other files that structually look identical, except for the names of classes they use, ex `MTLMaskBlit.java` and `OGLMaskBlit.java`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kizune at openjdk.java.net  Mon Feb  8 23:18:49 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 8 Feb 2021 23:18:49 GMT
Subject: <AWT Dev> RFR: 8261368: The new TestNullSetColor test is placed
 in the wrong group
In-Reply-To: <ACb_vI6tPHdmcsy6g9bb-JC6KpLttzic8l2PUyQ1xqo=.cf863ebf-ba13-4aaa-8ff6-d0efc007d9d5@github.com>
References: <ACb_vI6tPHdmcsy6g9bb-JC6KpLttzic8l2PUyQ1xqo=.cf863ebf-ba13-4aaa-8ff6-d0efc007d9d5@github.com>
Message-ID: <pFVelk-zpnsDNeE5xqh7dD8ybZsH74MWo8SCaNBm4E8=.d60e7e81-1a0e-49cb-9a87-754606b730cb@github.com>

On Mon, 8 Feb 2021 22:41:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test is moved to the "java/awt/Graphics/" since it validates behavior of the java.awt.Graphics$setColor() method.

Marked as reviewed by kizune (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2467

From serb at openjdk.java.net  Tue Feb  9 00:04:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 9 Feb 2021 00:04:45 GMT
Subject: <AWT Dev> Integrated: 8261368: The new TestNullSetColor test is
 placed in the wrong group
In-Reply-To: <ACb_vI6tPHdmcsy6g9bb-JC6KpLttzic8l2PUyQ1xqo=.cf863ebf-ba13-4aaa-8ff6-d0efc007d9d5@github.com>
References: <ACb_vI6tPHdmcsy6g9bb-JC6KpLttzic8l2PUyQ1xqo=.cf863ebf-ba13-4aaa-8ff6-d0efc007d9d5@github.com>
Message-ID: <uaZhF10g-5TzuApIA60zyDfHBq-4F8fwqTaHGN4FPsQ=.e0a55106-6f6f-4b4b-b055-99244d7fda27@github.com>

On Mon, 8 Feb 2021 22:41:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test is moved to the "java/awt/Graphics/" since it validates behavior of the java.awt.Graphics$setColor() method.

This pull request has now been integrated.

Changeset: 5d8204b1
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5d8204b1
Stats:     0 lines in 1 file changed: 0 ins; 0 del; 0 mod

8261368: The new TestNullSetColor test is placed in the wrong group

Reviewed-by: kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/2467

From aghaisas at openjdk.java.net  Tue Feb  9 07:37:41 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 9 Feb 2021 07:37:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <dXrkAzyW6Zq4W3IXyuWCQ0IFYhL0iNyFI_KHmqWeA8o=.986014a8-5f71-4879-b470-abf1558cefe9@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <026mUCt0l4yG3PQpIAOaI8yTKXuhZ5M7iEtYUevF-yM=.2a0f903a-31e4-4dce-bd7c-4dd76be77f1b@github.com>
 <1B1HMTCLZYlhhHBKTI8Phtg85X6LG_HJWtXCHFcHStk=.84e2dc10-0052-4c92-8296-4992329dba95@github.com>
 <dXrkAzyW6Zq4W3IXyuWCQ0IFYhL0iNyFI_KHmqWeA8o=.986014a8-5f71-4879-b470-abf1558cefe9@github.com>
Message-ID: <4LYtM2UWmcAzFYarXx_P6Lh9L65JVtpxT0vcy4Sb4yE=.b63e0aac-cfd4-4ac3-ae21-7944c2714ce2@github.com>

On Mon, 8 Feb 2021 14:22:27 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> I think, a generic name is OK as the path of shader file already has both awt (libawt_lwawt) and java2d in it.
>
> In the source tree, yes, but not in the jdk image where it ends up in `$JAVA_HOME/lib/shaders.metallib`. I don't have a problem with this, as long as it is a deliberate decision.

OK. I get your point. Keeping the name unchanged for now as there won't be another .metallib in JDK. The name can be changed in the future if need arises.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Tue Feb  9 12:29:52 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 9 Feb 2021 12:29:52 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)

Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:

 - Lanai PR#177 - 8261430 - aghaisas
 - Lanai PR#176 - 8261399 - jdv

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/6044adc0..64173289

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=02-03

  Stats: 49 lines in 14 files changed: 0 ins; 43 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Tue Feb  9 15:06:13 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Tue, 9 Feb 2021 15:06:13 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <rhOSngQoeE4RMbUdweZdQDVezQShNe-ucJ56FMcXszY=.6ba5b170-6d42-46a5-a3c1-c1ecfe6781af@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
 <rhOSngQoeE4RMbUdweZdQDVezQShNe-ucJ56FMcXszY=.6ba5b170-6d42-46a5-a3c1-c1ecfe6781af@github.com>
Message-ID: <1ixDTPfQyOMCa0BDtr8IDHGEjI-tCt9Szl1WtlyMuPs=.dd88d6b9-23d9-4068-8239-b07d5a102717@github.com>

On Mon, 8 Feb 2021 16:53:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lanai PR#175 - 8261304 - aghaisas
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsDevice.java line 113:
> 
>> 111:             // This indicates fallback to other rendering pipeline also failed.
>> 112:             // Should never reach here
>> 113:             throw new InternalError("Error - unable to initialize any rendering pipeline.");
> 
> There is no software based renderer to fall back here?

OpenGL was the sole rendering pipeline on macOS. Now we are adding Metal rendering pipeline. There is no software based fall back renderer.

> src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 66:
> 
>> 64:                        propString.equals("f") ||
>> 65:                        propString.equals("False") ||
>> 66:                        propString.equals("F"))
> 
> Shouldn't `1` and `0` be also allowed here?

No.
0 and 1 are not supported for existing VM options for rendering pipelines. We won't be adding it for metal pipeline either.

> src/java.desktop/macosx/classes/sun/java2d/MacOSFlags.java line 100:
> 
>> 98:                         oglState = PropertyState.ENABLED; // Enable default pipeline
>> 99:                         metalState = PropertyState.DISABLED; // Disable non-default pipeline
>> 100:                     }
> 
> This matches JEP 382 specification, but even when both GL is `false` and Metal is `false` we still get GL? There is no software based pipeline anymore?

OpenGL was the sole rendering pipeline on macOS. Now we are adding Metal rendering pipeline. There is no software based fall back renderer.

If user requests both - GL and Metal - as false - we shall use 'the default' pipeline.
Current default render pipeline on macOS is OpenGL.
Changing default render pipeline on macOS is not in the scope of this JEP.

> src/java.desktop/macosx/classes/sun/java2d/metal/MTLSurfaceData.java line 61:
> 
>> 59: 
>> 60: public abstract class MTLSurfaceData extends SurfaceData
>> 61:         implements AccelSurface {
> 
> `MTLSurfaceData` and `OGLSurfaceData` seem to share lots of the same code, isn't there a way to refactor the common code out?
> 
> There are other files that structually look identical, except for the names of classes they use, ex `MTLMaskBlit.java` and `OGLMaskBlit.java`.

Although it is a good suggestion, I do not recommend this refactoring - 
- We do not wish to destabilize proven OpenGL pipeline by refactoring - additional testing on OpenGL pipeline also would be needed.
- OpenGL pipeline on macOS might be removed once Apple removes OpenGL support from macOS - this will render this refactoring pointless.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From jdv at openjdk.java.net  Wed Feb 10 02:55:43 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Wed, 10 Feb 2021 02:55:43 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <rhOSngQoeE4RMbUdweZdQDVezQShNe-ucJ56FMcXszY=.6ba5b170-6d42-46a5-a3c1-c1ecfe6781af@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
 <rhOSngQoeE4RMbUdweZdQDVezQShNe-ucJ56FMcXszY=.6ba5b170-6d42-46a5-a3c1-c1ecfe6781af@github.com>
Message-ID: <0slvqlV6xJDuxYEedVOsMAxxGSJeqNAFr3nhM9huGmI=.de6a23b9-0feb-40e9-bfd8-0fe75b26415e@github.com>

On Mon, 8 Feb 2021 18:05:02 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lanai PR#175 - 8261304 - aghaisas
>
> src/java.desktop/macosx/classes/sun/java2d/metal/MTLRenderQueue.java line 97:
> 
>> 95:     public static void disposeGraphicsConfig(long pConfigInfo) {
>> 96:         MTLRenderQueue rq = getInstance();
>> 97:         rq.lock();
> 
> Is it allowed to have multiple `MTLRenderQueue` instances?
> 
> If not, then I see this pattern everywhere:
> 
>         MTLRenderQueue rq = getInstance();
>         rq.lock();
>         {
>           ...
>         }
>         rq.unlock();
> why not just do:
> 
>         MTLRenderQueue.lock();
>         {
>           ...
>         }
>         MTLRenderQueue.unlock();
> 
> and have `MTLRenderQueue.lock()` and `MTLRenderQueue.unlock()` implement getting the actual lock instance and locking/unlocking it?

Thanks for the recommendation. This is a common behavior among different pipelines :  D3D, OpenGL and Metal. Mentioned lock/unlock should be implemented in parent RenderQueue class after refactoring and it will hit other pipelines. Its better to not touch other pipelines as part of this JEP.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From psadhukhan at openjdk.java.net  Wed Feb 10 08:03:40 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Wed, 10 Feb 2021 08:03:40 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
Message-ID: <L_Hb7nCZ4M-Wlj75vkmeP2luzKLcaoRzrteva9kC2RQ=.8afd7218-e17c-47f3-ae59-74cd5a5c83ab@github.com>

On Tue, 9 Feb 2021 12:29:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Lanai PR#177 - 8261430 - aghaisas
>  - Lanai PR#176 - 8261399 - jdv

src/java.desktop/macosx/classes/sun/java2d/metal/MTLBlitLoops.java line 110:

> 108: //                         MTLSurfaceData.PF_BYTE_GRAY),
> 109: //                 new MTLSwToSurfaceBlit(SurfaceType.UshortGray,
> 110: //                         MTLSurfaceData.PF_USHORT_GRAY),

Probably we could remove this commented lines

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From serb at openjdk.java.net  Wed Feb 10 19:39:51 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 10 Feb 2021 19:39:51 GMT
Subject: <AWT Dev> RFR: 8257853: Remove dependencies on JNF's JNI
 utility functions in AWT and 2D code [v7]
In-Reply-To: <9LIG2LXOS4Yl5D1N-v-eSW20NV3c6syfkJoPv5a1dEM=.5fe6d13a-7d6b-4fcb-ab6a-d87545a61580@github.com>
References: <JPA7AbeDJ6-rybiMcmqWtNVhCHUMgyrd0qSYAzVboFA=.e493b133-84a4-4dd7-905b-58c654f6bb28@github.com>
 <frhVRl-6Ue5IuRknxg14XajrA96aZ7PrgR-JLDC2QR4=.c2b8f4cc-d83b-401e-966b-a3dc3f0f546c@github.com>
 <kcNIsmCBxOrp_n7LXtEFwJj8LwBiMsfgeOq8HfJqLIc=.13cd30b1-1fec-468a-b78b-480bddfa3633@github.com>
 <9LIG2LXOS4Yl5D1N-v-eSW20NV3c6syfkJoPv5a1dEM=.5fe6d13a-7d6b-4fcb-ab6a-d87545a61580@github.com>
Message-ID: <4ZAvQ-nrua8MgD9noQnPvo9D8FR4wwSz2bFj3OTpvrg=.d856a1f5-2d57-4ea7-aaba-005c8c925784@github.com>

On Sun, 20 Dec 2020 12:20:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> looks good to me.
>
> It is a mistake that this fix was integrated, actually without proper approval of the AWT side. It would be good to roll back it one way or another.

> I guess we disagree. I think this is better and simpler.

It is just horrible usage of macros in the objective-c code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1679

From gziemski at openjdk.java.net  Wed Feb 10 21:43:39 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 10 Feb 2021 21:43:39 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <Tly92FYVx0I86iM4X-57Z2CSLi0ypaTJDMRmyD9OtCg=.3f7a2e8c-159e-404a-9356-ae7fc835c69b@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
 <Tly92FYVx0I86iM4X-57Z2CSLi0ypaTJDMRmyD9OtCg=.3f7a2e8c-159e-404a-9356-ae7fc835c69b@github.com>
Message-ID: <UT3lvrANjs1LT0qOXtsS-2jwxo3OMQoHq_tFXxmuC8E=.18e7de10-9c30-4750-b47d-b8525d74aede@github.com>

On Mon, 8 Feb 2021 23:07:39 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lanai PR#175 - 8261304 - aghaisas
>
> Changes requested by gziemski (Committer).

I tried to code review the native implementation file, but Metal APIs is brand new to me and it's been a long while since I worked with graphics API, so I can't be of much help really.

The code I've looked at looked clean and nothing caught my eye. But it's a partial code review at best.

Good job!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Wed Feb 10 21:47:43 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 10 Feb 2021 21:47:43 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
Message-ID: <C_0hBhY7CmU6tJBnaZVVr7cU3zO7r_NHApcicfVJslY=.4ff613ca-c669-4495-b1dd-f291d0e5c839@github.com>

On Tue, 9 Feb 2021 12:29:52 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Lanai PR#177 - 8261430 - aghaisas
>  - Lanai PR#176 - 8261399 - jdv

Marked as reviewed by gziemski (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Wed Feb 10 21:47:44 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 10 Feb 2021 21:47:44 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v3]
In-Reply-To: <UT3lvrANjs1LT0qOXtsS-2jwxo3OMQoHq_tFXxmuC8E=.18e7de10-9c30-4750-b47d-b8525d74aede@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <EgEYZPjr-GVbQmtjQWrnp0KGbReeTORwy9aF_XHdM0c=.bfbdf85c-7497-4ec1-b63d-c68a4d6153da@github.com>
 <Tly92FYVx0I86iM4X-57Z2CSLi0ypaTJDMRmyD9OtCg=.3f7a2e8c-159e-404a-9356-ae7fc835c69b@github.com>
 <UT3lvrANjs1LT0qOXtsS-2jwxo3OMQoHq_tFXxmuC8E=.18e7de10-9c30-4750-b47d-b8525d74aede@github.com>
Message-ID: <dYRbkkf0FTcnj9lRf-6JyrshJvInIlc4A3ipz5ovb8M=.ad38e95b-59d4-46b7-9549-0b7fbefb8977@github.com>

On Wed, 10 Feb 2021 21:40:46 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Changes requested by gziemski (Committer).
>
> I tried to code review the native implementation files, but Metal APIs is brand new to me and it's been a long while since I worked with graphics API, so I can't be of much help really.
> 
> The code I've looked at looked clean and nothing caught my eye. But it's a partial code review at best.
> 
> Good job!

A small thing caught my eye when I was comparing OpenGL and Metal pipelines running J2Demo.jar

It looks to me like OpenGL rendering pipeline uses brighter colors. I prefer the more subdued colors that Metal is rendering, but not sure if this is something you want to investigate further.

I tried to capture what I see below:

OpenGL:

<img width="1128" alt="OpenGL" src="https://user-images.githubusercontent.com/63425797/107575744-dc0ca180-6bb5-11eb-9eb3-5cff415eb8a3.png">

Metal (the green color has a yellowish tint):

<img width="1125" alt="Metal" src="https://user-images.githubusercontent.com/63425797/107575716-cf884900-6bb5-11eb-8ae8-14212ec94e87.png">

Performance wise I did not see much difference either way.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Wed Feb 10 22:33:41 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 10 Feb 2021 22:33:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <C_0hBhY7CmU6tJBnaZVVr7cU3zO7r_NHApcicfVJslY=.4ff613ca-c669-4495-b1dd-f291d0e5c839@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
 <C_0hBhY7CmU6tJBnaZVVr7cU3zO7r_NHApcicfVJslY=.4ff613ca-c669-4495-b1dd-f291d0e5c839@github.com>
Message-ID: <f2230IcQCQblWPDDX1pyv7CDe012OHL8WRtXsmF2SnY=.c20a5a66-6218-4730-bcde-0fd62cb0aa01@github.com>

On Wed, 10 Feb 2021 21:45:37 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lanai PR#177 - 8261430 - aghaisas
>>  - Lanai PR#176 - 8261399 - jdv
>
> Marked as reviewed by gziemski (Committer).

According to Xcode Instruments leak profile, there are 2 minor memory leaks in the Metal rendering pipeline:

`#1 Malloc 80 Bytes	1	0x7fde0d4247b0	80 Bytes	libjava.dylib	getStringUTF8`
   0 libsystem_malloc.dylib malloc_zone_malloc
   1 libsystem_malloc.dylib malloc
   2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
   3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
   4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_getMTLConfigInfo /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:151
   5  0x11ab08d48
   6  0x11ab0250d

`#2 Malloc 80 Bytes	1	0x7fde0d4325a0	80 Bytes	libjava.dylib	getStringUTF8`
   0 libsystem_malloc.dylib malloc_zone_malloc
   1 libsystem_malloc.dylib malloc
   2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
   3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
   4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_tryLoadMetalLibrary /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:120
   5  0x11ab08d48
   6  0x11ab024c8

Those can be handled as a followup issues though if you like, it's only 160 bytes total.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Thu Feb 11 04:32:00 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Feb 2021 04:32:00 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v5]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <kYlfYd7y-AjttGH1XItq2CJIchFa3p-RIvXxIvW4WmQ=.e9b7ecfc-73f7-4bf5-8c7f-3b880d35ccce@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into 8260931_lanai_JEP_branch
   Merge
 - Lanai PR#177 - 8261430 - aghaisas
 - Lanai PR#176 - 8261399 - jdv
 - Lanai PR#175 - 8261304 - aghaisas
 - Lanai PR#174 - 8261234 - kcr
 - Merge branch 'master' into 8260931_lanai_JEP_branch
   Merge from openjdk/jdk
 - Project Lanai Patch

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/64173289..9a72538a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=03-04

  Stats: 6660 lines in 320 files changed: 3899 ins; 1099 del; 1662 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Thu Feb 11 04:36:54 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Feb 2021 04:36:54 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v6]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <Hdh9RXJOqGb_FTcGlun05luFEg48V-S52Yroj1UKNnw=.8c2c8b4b-3d19-4d28-89a9-30416a09e589@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:

 - Lanai PR#179 - 8261402 - avu
 - Lanai PR#178 - 8261273 - avu

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/9a72538a..6a3f96ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=04-05

  Stats: 73 lines in 6 files changed: 9 ins; 39 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Thu Feb 11 05:43:41 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Feb 2021 05:43:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <f2230IcQCQblWPDDX1pyv7CDe012OHL8WRtXsmF2SnY=.c20a5a66-6218-4730-bcde-0fd62cb0aa01@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
 <C_0hBhY7CmU6tJBnaZVVr7cU3zO7r_NHApcicfVJslY=.4ff613ca-c669-4495-b1dd-f291d0e5c839@github.com>
 <f2230IcQCQblWPDDX1pyv7CDe012OHL8WRtXsmF2SnY=.c20a5a66-6218-4730-bcde-0fd62cb0aa01@github.com>
Message-ID: <2AcLShc7fiFnUrZXE4DHp-CgIR9ovet1ZqGJoSBTJ7E=.d5a3e162-d524-4710-bc97-4866b841c999@github.com>

On Wed, 10 Feb 2021 22:31:12 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Marked as reviewed by gziemski (Committer).
>
> According to Xcode Instruments leak profile, there are 2 minor memory leaks in the Metal rendering pipeline:
> 
> `#1 Malloc 80 Bytes	1	0x7fde0d4247b0	80 Bytes	libjava.dylib	getStringUTF8`
>    0 libsystem_malloc.dylib malloc_zone_malloc
>    1 libsystem_malloc.dylib malloc
>    2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
>    3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
>    4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_getMTLConfigInfo /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:151
>    5  0x11ab08d48
>    6  0x11ab0250d
> 
> `#2 Malloc 80 Bytes	1	0x7fde0d4325a0	80 Bytes	libjava.dylib	getStringUTF8`
>    0 libsystem_malloc.dylib malloc_zone_malloc
>    1 libsystem_malloc.dylib malloc
>    2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
>    3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
>    4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_tryLoadMetalLibrary /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:120
>    5  0x11ab08d48
>    6  0x11ab024c8
> 
> Those can be handled as a followup issues though if you like, it's only 160 bytes total.

> I tried to code review the native implementation files, but Metal APIs is brand new to me and it's been a long while since I worked with graphics API, so I can't be of much help really.
> 
> The code I've looked at looked clean and nothing caught my eye. But it's a partial code review at best.
> 
> Good job!

Every bit helps. Thanks for your review effort!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From jdv at openjdk.java.net  Thu Feb 11 07:13:39 2021
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Thu, 11 Feb 2021 07:13:39 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v4]
In-Reply-To: <2AcLShc7fiFnUrZXE4DHp-CgIR9ovet1ZqGJoSBTJ7E=.d5a3e162-d524-4710-bc97-4866b841c999@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <Zu4C_vH_e_Vdhs4jvIbJQJu9Ha9HsBV5xwdFcFW6seU=.0691ab8c-e7ac-45ed-a65e-96e711f636d1@github.com>
 <C_0hBhY7CmU6tJBnaZVVr7cU3zO7r_NHApcicfVJslY=.4ff613ca-c669-4495-b1dd-f291d0e5c839@github.com>
 <f2230IcQCQblWPDDX1pyv7CDe012OHL8WRtXsmF2SnY=.c20a5a66-6218-4730-bcde-0fd62cb0aa01@github.com>
 <2AcLShc7fiFnUrZXE4DHp-CgIR9ovet1ZqGJoSBTJ7E=.d5a3e162-d524-4710-bc97-4866b841c999@github.com>
Message-ID: <ENSKkE-m7sDrtCcKjo-DnNiJxzLQ4dLYtWyAXRHb3Gg=.c5e1239a-b19e-484f-905e-ddb1c9c8b4da@github.com>

On Thu, 11 Feb 2021 05:41:15 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> According to Xcode Instruments leak profile, there are 2 minor memory leaks in the Metal rendering pipeline:
>> 
>> `#1 Malloc 80 Bytes	1	0x7fde0d4247b0	80 Bytes	libjava.dylib	getStringUTF8`
>>    0 libsystem_malloc.dylib malloc_zone_malloc
>>    1 libsystem_malloc.dylib malloc
>>    2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
>>    3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
>>    4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_getMTLConfigInfo /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:151
>>    5  0x11ab08d48
>>    6  0x11ab0250d
>> 
>> `#2 Malloc 80 Bytes	1	0x7fde0d4325a0	80 Bytes	libjava.dylib	getStringUTF8`
>>    0 libsystem_malloc.dylib malloc_zone_malloc
>>    1 libsystem_malloc.dylib malloc
>>    2 libjava.dylib getStringUTF8 /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:888
>>    3 libjava.dylib JNU_GetStringPlatformChars /Volumes/Work/review/2403/jdk/src/java.base/share/native/libjava/jni_util.c:917
>>    4 libawt_lwawt.dylib Java_sun_java2d_metal_MTLGraphicsConfig_tryLoadMetalLibrary /Volumes/Work/review/2403/jdk/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m:120
>>    5  0x11ab08d48
>>    6  0x11ab024c8
>> 
>> Those can be handled as a followup issues though if you like, it's only 160 bytes total.
>
>> I tried to code review the native implementation files, but Metal APIs is brand new to me and it's been a long while since I worked with graphics API, so I can't be of much help really.
>> 
>> The code I've looked at looked clean and nothing caught my eye. But it's a partial code review at best.
>> 
>> Good job!
> 
> Every bit helps. Thanks for your review effort!

> A small thing caught my eye when I was comparing OpenGL and Metal pipelines running J2Demo.jar
> 
> It looks to me like OpenGL rendering pipeline uses brighter colors. I prefer the more subdued colors that Metal is rendering, but not sure if this is something you want to investigate further.
> 
> I tried to capture what I see below:
> 
> OpenGL:
> 
> <img alt="OpenGL" width="1128" src="https://user-images.githubusercontent.com/63425797/107575744-dc0ca180-6bb5-11eb-9eb3-5cff415eb8a3.png">
> 
> Metal (the green color has a yellowish tint):
> 
> <img alt="Metal" width="1125" src="https://user-images.githubusercontent.com/63425797/107575716-cf884900-6bb5-11eb-8ae8-14212ec94e87.png">
> 
> Performance wise I did not see much difference either way.

@gerard-ziemski Thanks for verifying the behavior.
Text present in Memory monitor/Performance in J2DDemo is not drawn using Metal rendering pipeline(drawGlyphList or any other rendering opcodes, I have verified it again in latest code). This is drawn using software renderloops and only thing happens from Metal pipeline is this content is used in blit opcode. Slight difference in color that we are seeing is related to how Metal internally handles blending of colors.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From avu at openjdk.java.net  Thu Feb 11 07:38:40 2021
From: avu at openjdk.java.net (Alexey Ushakov)
Date: Thu, 11 Feb 2021 07:38:40 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v6]
In-Reply-To: <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <8YBuOeDAPN2osBnW5cyN-91hYtg7malBqDlJZsgWrPk=.6c99ab50-76a8-4686-85dd-5918abfdacf0@github.com>
Message-ID: <cF93rq_YuzpQMc-avMjkketM1ajpYre3JGHTdW4RR7E=.0cc1040f-0955-43fc-941a-32c5fee420d4@github.com>

On Fri, 5 Feb 2021 22:59:43 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lanai PR#179 - 8261402 - avu
>>  - Lanai PR#178 - 8261273 - avu
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLTexurePool.m line 29:
> 
>> 27: #import "Trace.h"
>> 28: 
>> 29: #define SCREEN_MEMORY_SIZE_4K (4096*2160*4) //~33,7 mb
> 
> This means that a 4k display with a narrower aspect ratio wouldn't fit (assuming there ever were to be such a thing). What would happen if you encountered a screen that was, say, 4k * 2.5K?

This parameter manages our caching strategy for the temporary texture pool. Huge texture allocations 4K/2 size will cause texture pool drain. We need some more profiling to just these parameters. And I think we need to use Metal API (https://developer.apple.com/documentation/metal/mtldevice/2369280-recommendedmaxworkingsetsize?language=objc) in the future to adjust the amount of memory that we should use.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Thu Feb 11 11:51:57 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Thu, 11 Feb 2021 11:51:57 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:

 - Lanai PR#181 - 8261143 - aghaisas
 - Lanai PR#180 - 8261546 - jdv

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/6a3f96ef..7340d067

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=05-06

  Stats: 82 lines in 2 files changed: 0 ins; 54 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Thu Feb 11 21:01:44 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 11 Feb 2021 21:01:44 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
Message-ID: <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>

On Thu, 11 Feb 2021 11:51:57 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Lanai PR#181 - 8261143 - aghaisas
>  - Lanai PR#180 - 8261546 - jdv

Changes requested by gziemski (Committer).

src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 112:

> 110:                 sourceSize:MTLSizeMake(self.buffer.width, self.buffer.height, 1)
> 111:                 toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
> 112:         [blitEncoder endEncoding];

There is an issue with this code. Running Java2D.jar in Xcode asserts here with this message:

2021-02-11 14:11:45.710457-0600 java[49971:9486360] Metal API Validation Enabled
2021-02-11 14:11:46.038720-0600 system_profiler[49975:9486885] Metal API Validation Enabled
-[MTLDebugBlitCommandEncoder internalValidateCopyFromTexture:sourceSlice:sourceLevel:sourceOrigin:sourceSize:toTexture:destinationSlice:destinationLevel:destinationOrigin:options:]:474: failed assertion `(sourceOrigin.y + sourceSize.height)(444) must be <= height(400).'
(lldb) 

and forcing the execution past it results in the java process crashing.

A solution would be to clip the src size like this:

        NSUInteger src_x = self.leftInset*self.contentsScale;
        NSUInteger src_y = self.topInset*self.contentsScale;
        NSUInteger src_w = self.buffer.width-src_x;
        NSUInteger src_h = self.buffer.height-src_y;
        
        [blitEncoder
                copyFromTexture:self.buffer sourceSlice:0 sourceLevel:0
                sourceOrigin:MTLOriginMake((jint)src_x, (jint)src_y, 0)
                sourceSize:MTLSizeMake(src_w, src_h, 1)
                toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
        [blitEncoder endEncoding];

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Thu Feb 11 21:01:45 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 11 Feb 2021 21:01:45 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
Message-ID: <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>

On Thu, 11 Feb 2021 20:55:35 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lanai PR#181 - 8261143 - aghaisas
>>  - Lanai PR#180 - 8261546 - jdv
>
> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 112:
> 
>> 110:                 sourceSize:MTLSizeMake(self.buffer.width, self.buffer.height, 1)
>> 111:                 toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
>> 112:         [blitEncoder endEncoding];
> 
> There is an issue with this code. Running Java2D.jar in Xcode asserts here with this message:
> 
> 2021-02-11 14:11:45.710457-0600 java[49971:9486360] Metal API Validation Enabled
> 2021-02-11 14:11:46.038720-0600 system_profiler[49975:9486885] Metal API Validation Enabled
> -[MTLDebugBlitCommandEncoder internalValidateCopyFromTexture:sourceSlice:sourceLevel:sourceOrigin:sourceSize:toTexture:destinationSlice:destinationLevel:destinationOrigin:options:]:474: failed assertion `(sourceOrigin.y + sourceSize.height)(444) must be <= height(400).'
> (lldb) 
> 
> and forcing the execution past it results in the java process crashing.
> 
> A solution would be to clip the src size like this:
> 
>         NSUInteger src_x = self.leftInset*self.contentsScale;
>         NSUInteger src_y = self.topInset*self.contentsScale;
>         NSUInteger src_w = self.buffer.width-src_x;
>         NSUInteger src_h = self.buffer.height-src_y;
>         
>         [blitEncoder
>                 copyFromTexture:self.buffer sourceSlice:0 sourceLevel:0
>                 sourceOrigin:MTLOriginMake((jint)src_x, (jint)src_y, 0)
>                 sourceSize:MTLSizeMake(src_w, src_h, 1)
>                 toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
>         [blitEncoder endEncoding];

I guess you will only see this if `Metal API Validation Enabled`

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Thu Feb 11 21:06:41 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 11 Feb 2021 21:06:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>
Message-ID: <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>

On Thu, 11 Feb 2021 20:58:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLLayer.m line 112:
>> 
>>> 110:                 sourceSize:MTLSizeMake(self.buffer.width, self.buffer.height, 1)
>>> 111:                 toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
>>> 112:         [blitEncoder endEncoding];
>> 
>> There is an issue with this code. Running Java2D.jar in Xcode asserts here with this message:
>> 
>> 2021-02-11 14:11:45.710457-0600 java[49971:9486360] Metal API Validation Enabled
>> 2021-02-11 14:11:46.038720-0600 system_profiler[49975:9486885] Metal API Validation Enabled
>> -[MTLDebugBlitCommandEncoder internalValidateCopyFromTexture:sourceSlice:sourceLevel:sourceOrigin:sourceSize:toTexture:destinationSlice:destinationLevel:destinationOrigin:options:]:474: failed assertion `(sourceOrigin.y + sourceSize.height)(444) must be <= height(400).'
>> (lldb) 
>> 
>> and forcing the execution past it results in the java process crashing.
>> 
>> A solution would be to clip the src size like this:
>> 
>>         NSUInteger src_x = self.leftInset*self.contentsScale;
>>         NSUInteger src_y = self.topInset*self.contentsScale;
>>         NSUInteger src_w = self.buffer.width-src_x;
>>         NSUInteger src_h = self.buffer.height-src_y;
>>         
>>         [blitEncoder
>>                 copyFromTexture:self.buffer sourceSlice:0 sourceLevel:0
>>                 sourceOrigin:MTLOriginMake(src_x, src_y, 0)
>>                 sourceSize:MTLSizeMake(src_w, src_h, 1)
>>                 toTexture:mtlDrawable.texture destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(0, 0, 0)];
>>         [blitEncoder endEncoding];
>
> I guess you will only see this if `Metal API Validation Enabled`

Which actually begs a question of whether we tested with `Metal API Validation Enabled` ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From prr at openjdk.java.net  Thu Feb 11 23:12:39 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 11 Feb 2021 23:12:39 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>
 <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>
Message-ID: <pcEYAYMilWyyRXaUWoD23OmgVfMdvKovCEOcDQ_6etA=.4c7527c1-abe6-4b47-9099-98cd7ddfb48e@github.com>

On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> I guess you will only see this if `Metal API Validation Enabled`
>
> Which actually begs a question of whether we tested with `Metal API Validation Enabled` ?

I submitted https://bugs.openjdk.java.net/browse/JDK-8261620 for this bug.
Could be that there are more such issues but since this crash occurs on start up I can't say what else there might be.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From philip.race at oracle.com  Fri Feb 12 01:06:45 2021
From: philip.race at oracle.com (Philip Race)
Date: Thu, 11 Feb 2021 17:06:45 -0800
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <pcEYAYMilWyyRXaUWoD23OmgVfMdvKovCEOcDQ_6etA=.4c7527c1-abe6-4b47-9099-98cd7ddfb48e@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>
 <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>
 <pcEYAYMilWyyRXaUWoD23OmgVfMdvKovCEOcDQ_6etA=.4c7527c1-abe6-4b47-9099-98cd7ddfb48e@github.com>
Message-ID: <9070fb5a-4ffa-9e37-5e79-1c0de3d685e0@oracle.com>

I have worked out how to pass this option to at least the jtreg tests 
for the lanai headful mach5 job,
so once this is fixed we can check it out in jtreg and get some level of 
confidence? that we are
checking all the important cases.
Note that we know some tests will fail just because it spits out a 
message that they will mis-parse but it is still worth doing.

Need to figure out the same for JCK ..

-phil.

On 2/11/21 3:12 PM, Phil Race wrote:
> On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:
>
>>> I guess you will only see this if `Metal API Validation Enabled`
>> Which actually begs a question of whether we tested with `Metal API Validation Enabled` ?
> I submitted https://bugs.openjdk.java.net/browse/JDK-8261620 for this bug.
> Could be that there are more such issues but since this crash occurs on start up I can't say what else there might be.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2403


From aghaisas at openjdk.java.net  Fri Feb 12 09:30:42 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Fri, 12 Feb 2021 09:30:42 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <l62WYcHSTQqk-KgrEFiSbKjAxVfG1_Z1re0XYQmS3W8=.13339dbb-8ea8-44fb-a881-4950cdb2f274@github.com>
 <Ye80y1ePTbe0KNF6OV-qz-Z-s3fI8IzL6Xf3sE2DhU0=.a7dd8557-69b0-430a-b93e-b75fd32e28ff@github.com>
Message-ID: <jadQALbYlHsxejSjfTRi-x1TYxtBU42WrF_5D45o4sU=.13aa5819-370d-48e6-916b-4964f618f79b@github.com>

On Thu, 11 Feb 2021 21:04:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> I guess you will only see this if `Metal API Validation Enabled`
>
> Which actually begs a question of whether we tested with `Metal API Validation Enabled` ?

Thanks @gerard-ziemski for bringing out this important observation. It clearly indicates that there are some overflows which are undetected.

We have tested without Metal API validation enabled till now.
 
Now, I have fixed the JDK-8261620 bug that reported the crash on app launch with Metal API validation enabled.
More testing with ?Metal API validation enabled? to follow..

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From omikhaltcova at openjdk.java.net  Fri Feb 12 21:43:56 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 12 Feb 2021 21:43:56 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v3]
In-Reply-To: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
Message-ID: <59jhaSZ-ekCP39Y_qcaSCTVo8VRCmtjnvWxj1i_ZS9k=.b882bde5-40c6-4da6-8287-5937ea7d4fa1@github.com>

> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on!
> 
> This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H).
> 
> The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. 
> 
> Testing is quite complicated because for reproducing this bug the following conditions should be met:
> 1.	HiDPI is turned on
> 2.	sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100%
> 3.	the source of drag-n-drop is non-java application
> 
> The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414.

Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:

  8257414: Drag n Drop target area is wrong on high DPI systems

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1907/files
  - new: https://git.openjdk.java.net/jdk/pull/1907/files/e4c1c73d..d8259bdf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1907&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1907&range=01-02

  Stats: 32 lines in 1 file changed: 2 ins; 17 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1907.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1907/head:pull/1907

PR: https://git.openjdk.java.net/jdk/pull/1907

From omikhaltcova at openjdk.java.net  Fri Feb 12 21:55:42 2021
From: omikhaltcova at openjdk.java.net (Olga Mikhaltsova)
Date: Fri, 12 Feb 2021 21:55:42 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v2]
In-Reply-To: <y08RKlQcqHLRrERSQLmJ05dQS2SqKXFJN8mclidulAE=.83938572-9f2b-44ff-84da-24e0be1c146c@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
 <r_29BJgyyg89MweV8NPnu88uwEdzGCblNRFZjbfZnuk=.a7dbfe78-c89c-4ab2-83f9-1a0b1569f306@github.com>
 <y08RKlQcqHLRrERSQLmJ05dQS2SqKXFJN8mclidulAE=.83938572-9f2b-44ff-84da-24e0be1c146c@github.com>
Message-ID: <u97YI2k6WfnWLOosYdPFnRSvD-7L0PaZnndjiCqiSBA=.27d5b15e-bc77-483c-84be-e40982f5d21f@github.com>

On Sat, 6 Feb 2021 02:26:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8257414: Drag n Drop target area is wrong on high DPI systems
>
> src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 618:
> 
>> 616:             try {
>> 617:                 for (int i = 0; i < gdslen; i++) {
>> 618:                     long screenRoot = XlibWrapper.RootWindow(display, i);
> 
> I am not sure this will work in the multi-monitors configuration when the screen is split across a few monitors(when Xinerama is enabled for example). In such a configuration, only one root window and only one X11 screen exist. And the index of the GraphicsDevice is the index of the "virtual" monitor, so you cannot pass this index to the "XlibWrapper.RootWindow".
> 
> A few questions:
> * Are you sure that to scale the x/y in the device space you need to find where the pointer is located? And not where the x/y coordinates are located themselves?
> * Did you try to iterate over the devices->downscale the bounds of each GD to the device scale and upscale the x/y using the selected device. Such utility method can be added to the SunGraphicsEnvironment

Sergey, thanks for the hint! Hope I understand you right. Please, review my changes!

I decided to do necessary scaling in place and not to add an utility method to SunGraphicsEnvironment due to the following doubts: 
the methods from SunGraphicsEnvironment can be called from different OS and I'm going to use GraphicsConfig::getBounds() but I see that the Unix implementation includes downscaling (X11GraphicsConfig::getBounds(), src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java) and the Windows one is not (Win32GraphicsConfig::getBounds(), src/java.desktop/windows/classes/sun/awt/Win32GraphicsConfig.java); 
so for Unix I need upscaling before checking the point position but for Windows it is not needed. 
Please, correct me if I'm wrong!

Concerning my previous implementation based on the cursor position, would you be so kind to take a look at XMouseInfoPeer::fillPointWithCoords(..) (src/java.desktop/unix/classes/sun/awt/X11/XMouseInfoPeer.java) in order to check whether it should be also fixed?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1907

From kizune at openjdk.java.net  Sat Feb 13 05:06:51 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 13 Feb 2021 05:06:51 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol
Message-ID: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>

8261351: Create implementation for NSAccessibilityRadioButton protocol

-------------

Commit messages:
 - 8261351: Create implementation for NSAccessibilityRadioButton protocol

Changes: https://git.openjdk.java.net/jdk/pull/2561/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2561&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261351
  Stats: 47 lines in 3 files changed: 44 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2561/head:pull/2561

PR: https://git.openjdk.java.net/jdk/pull/2561

From pbansal at openjdk.java.net  Sat Feb 13 05:30:40 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 13 Feb 2021 05:30:40 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol
In-Reply-To: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
Message-ID: <Vb5r1MtPP4zJ-XVL1YpDzphIsrLiBBbqfjdtIKJXLc4=.058c181d-7084-47b6-80ef-810bde42a013@github.com>

On Sat, 13 Feb 2021 05:01:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261351: Create implementation for NSAccessibilityRadioButton protocol

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.m line 39:

> 37:     AWT_ASSERT_APPKIT_THREAD;
> 38:     id value = [self accessibilityValueAttribute];
> 39:     return value;

Why to create value variable? Can we just do "return [self accessibilityValueAttribute];"

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From pbansal at openjdk.java.net  Sat Feb 13 05:33:39 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 13 Feb 2021 05:33:39 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol
In-Reply-To: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
Message-ID: <rYzfTEvFi_l3j74NEaXu6wiJAQQvEoFTNwn-X4Tz7Jc=.06b91910-61cf-415a-82eb-5cddf77ca7ee@github.com>

On Sat, 13 Feb 2021 05:01:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261351: Create implementation for NSAccessibilityRadioButton protocol

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.h line 35:

> 33: 
> 34: };
> 35: - (id)accessibilityValue;

The NSAccessibilityRadioButton protocol has NSNumber as return type. Is it fine to return id? I know id will be NSNumber pointer, but should not we make it clear that NSNumber is supposed to be returned?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From kizune at openjdk.java.net  Sat Feb 13 05:55:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 13 Feb 2021 05:55:02 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v2]
In-Reply-To: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
Message-ID: <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>

> 8261351: Create implementation for NSAccessibilityRadioButton protocol

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Internal variable eliminated.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2561/files
  - new: https://git.openjdk.java.net/jdk/pull/2561/files/e48192a0..bd2be1ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2561&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2561&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2561/head:pull/2561

PR: https://git.openjdk.java.net/jdk/pull/2561

From kizune at openjdk.java.net  Sat Feb 13 05:55:03 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 13 Feb 2021 05:55:03 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v2]
In-Reply-To: <rYzfTEvFi_l3j74NEaXu6wiJAQQvEoFTNwn-X4Tz7Jc=.06b91910-61cf-415a-82eb-5cddf77ca7ee@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
 <rYzfTEvFi_l3j74NEaXu6wiJAQQvEoFTNwn-X4Tz7Jc=.06b91910-61cf-415a-82eb-5cddf77ca7ee@github.com>
Message-ID: <7hlDyvEiMoFUUfGteiLLLB4t709uidhtAuXZ-Q60slo=.68b4f9e8-28fa-4fcb-a433-f5c05e6804ae@github.com>

On Sat, 13 Feb 2021 05:31:18 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internal variable eliminated.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.h line 35:
> 
>> 33: 
>> 34: };
>> 35: - (id)accessibilityValue;
> 
> The NSAccessibilityRadioButton protocol has NSNumber as return type. Is it fine to return id? I know id will be NSNumber pointer, but should not we make it clear that NSNumber is supposed to be returned?

No, it's Ok to return id here just to avoid type cast.

> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.m line 39:
> 
>> 37:     AWT_ASSERT_APPKIT_THREAD;
>> 38:     id value = [self accessibilityValueAttribute];
>> 39:     return value;
> 
> Why to create value variable? Can we just do "return [self accessibilityValueAttribute];"

Ah, that was a leftover from the debugging, i tried to return different types. Can be eliminated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From pbansal at openjdk.java.net  Sat Feb 13 07:15:40 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 13 Feb 2021 07:15:40 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v2]
In-Reply-To: <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
 <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>
Message-ID: <uI3ihV-ZJnHl8MGY0sYcdtA4s0XAgjCM1Ay0_NfpHCw=.d7ff16db-389b-432d-92b1-9d055ea9b115@github.com>

On Sat, 13 Feb 2021 05:55:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8261351: Create implementation for NSAccessibilityRadioButton protocol
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Internal variable eliminated.

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From pbansal at openjdk.java.net  Sat Feb 13 08:45:40 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Sat, 13 Feb 2021 08:45:40 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v2]
In-Reply-To: <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
 <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>
Message-ID: <HnZkj95r7jrbIWwiZl5BUlaTjezzqD84M1wMuHIbEmw=.67474c67-d4f5-42e1-a2a2-6feb5d04ff92@github.com>

On Sat, 13 Feb 2021 05:55:02 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> 8261351: Create implementation for NSAccessibilityRadioButton protocol
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Internal variable eliminated.

src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.h line 28:

> 26: #import "JavaComponentAccessibility.h"
> 27: #import "CommonComponentAccessibility.h"
> 28: #import "ButtonAccessibility.h"

Just a nit-pick and you can choose to ignore if you feel so. You can remove the JavaComponentAccessibility.h and CommonComponentAccessibility.h from imports here as they have already been imported in ButtonAccessibility.h

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From kizune at openjdk.java.net  Sun Feb 14 07:20:58 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 14 Feb 2021 07:20:58 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v3]
In-Reply-To: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
Message-ID: <ZaHio1o05xjC-zDPqUg8h08x2ExNEYJidLLuqw9zyEU=.ef417926-1555-4b46-b4a7-249bb4fcd7d6@github.com>

> 8261351: Create implementation for NSAccessibilityRadioButton protocol

Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:

  Imports simplified.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2561/files
  - new: https://git.openjdk.java.net/jdk/pull/2561/files/bd2be1ca..aacf8bc5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2561&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2561&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2561.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2561/head:pull/2561

PR: https://git.openjdk.java.net/jdk/pull/2561

From kizune at openjdk.java.net  Sun Feb 14 07:20:59 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sun, 14 Feb 2021 07:20:59 GMT
Subject: <AWT Dev> RFR: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol [v2]
In-Reply-To: <HnZkj95r7jrbIWwiZl5BUlaTjezzqD84M1wMuHIbEmw=.67474c67-d4f5-42e1-a2a2-6feb5d04ff92@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
 <DWh12MtXHdrcDDhbLJkPm9WbBDu3Qd1ERrjN1fWO4ag=.7a893f51-be87-4cb6-badf-8f2a2d2a8469@github.com>
 <HnZkj95r7jrbIWwiZl5BUlaTjezzqD84M1wMuHIbEmw=.67474c67-d4f5-42e1-a2a2-6feb5d04ff92@github.com>
Message-ID: <e_eCt6CRQwef8Z6Hm2MqbcJ6s8RK2QtPlXHRa-VgzVU=.1c4634f7-23fc-4f6a-b9cb-a92ce147baf9@github.com>

On Sat, 13 Feb 2021 08:42:26 GMT, Pankaj Bansal <pbansal at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Internal variable eliminated.
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/RadiobuttonAccessibility.h line 28:
> 
>> 26: #import "JavaComponentAccessibility.h"
>> 27: #import "CommonComponentAccessibility.h"
>> 28: #import "ButtonAccessibility.h"
> 
> Just a nit-pick and you can choose to ignore if you feel so. You can remove the JavaComponentAccessibility.h and CommonComponentAccessibility.h from imports here as they have already been imported in ButtonAccessibility.h

No, you are right, imports should be simplified here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From aghaisas at openjdk.java.net  Mon Feb 15 06:24:13 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 15 Feb 2021 06:24:13 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v8]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <alfbii4uc4NQLgHs1q26Yrjxx5bmtDWoEDjA2BUAfW8=.9264bf96-068b-4864-80e9-c83d16d5c53e@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Lanai PR#191 - 8261705 - jdv
 - Lanai PR#190 - 8261706 - jdv
 - Lanai PR#189 - 8261712 - avu
 - Lanai PR#187 - 8261704 - jdv
 - Lanai PR#186 - 8261638 - avu
 - Lanai PR#185 - 8261632 - jdv
 - Lanai PR#184 - 8261620 - aghaisas
 - Lanai PR#182 - 8261547 - psadhukhan
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#181 - 8261143 - aghaisas
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/89c20e04...7b0b0dc4

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/7340d067..7b0b0dc4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=06-07

  Stats: 6664 lines in 263 files changed: 3414 ins; 1659 del; 1591 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Mon Feb 15 18:34:41 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 15 Feb 2021 18:34:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
Message-ID: <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>

On Thu, 11 Feb 2021 20:55:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Lanai PR#181 - 8261143 - aghaisas
>>  - Lanai PR#180 - 8261546 - jdv
>
> Changes requested by gziemski (Committer).

I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a startup time regression with the Metal rendering pipeline, so I dug a bit and here is what I found using Xcode startup profiler:

Here is the OpenGL pipeline:
<img width="1904" alt="OpenGL" src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png">


Here is the Metal pipeline:
<img width="1904" alt="Metal" src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png">

If I read the results correctly, there is a weird 330ms time gap in the case of the Metal pipeline where nothing is done and it looks like the culprit is `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable`

The OpenGL pipeline gets blocked only for 83ms in `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo`

I would advice that we take a closer look at why 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so long, and optimize it, or cache the results, so the next VM instance can skip it if needed (assuming the call doesn't end up initializing the native Metal or something like that), still worth taking a look.

I would also recommend that you adopt Xcode and its Instruments profiler tools for future work. Please let me know if you need help in this area.

I only scratched the surface here and I think that there is plenty of profiling that can be done to investigate the startup time regression further.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From aghaisas at openjdk.java.net  Mon Feb 15 18:56:42 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Mon, 15 Feb 2021 18:56:42 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
Message-ID: <hun11VDha4ceo2QWHUo6f0XAQPN-55BveAsJPZ3THuA=.2c48b389-4fb3-4faa-9e6c-484ce749bff3@github.com>

On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Changes requested by gziemski (Committer).
>
> I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a startup time regression with the Metal rendering pipeline, so I dug a bit and here is what I found using Xcode startup profiler:
> 
> Here is the OpenGL pipeline:
> <img width="1904" alt="OpenGL" src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png">
> 
> 
> Here is the Metal pipeline:
> <img width="1904" alt="Metal" src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png">
> 
> If I read the results correctly, there is a weird 330ms time gap in the case of the Metal pipeline where nothing is done and it looks like the culprit is `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable`
> 
> The OpenGL pipeline gets blocked only for 83ms in `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo`
> 
> I would advice that we take a closer look at why 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so long, and optimize it, or cache the results, so the next VM instance can skip it if needed (assuming the call doesn't end up initializing the native Metal or something like that), still worth taking a look.
> 
> I would also recommend that you adopt Xcode and its Instruments profiler tools for future work. Please let me know if you need help in this area.
> 
> I only scratched the surface here and I think that there is plenty of profiling that can be done to investigate the startup time regression further.

Thanks @gerard-ziemski for taking a detailed look at this.
We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kizune at openjdk.java.net  Mon Feb 15 19:06:43 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 15 Feb 2021 19:06:43 GMT
Subject: <AWT Dev> Integrated: 8261351: Create implementation for
 NSAccessibilityRadioButton protocol
In-Reply-To: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
References: <j1G89TJbDBC_V1TRyax6YZcBKxuM6xqXWcELcd74FyE=.84c3d091-5a80-4ea0-8929-e54f6fa2a9f7@github.com>
Message-ID: <OaSnRaWomrSiWAhB9mAL2b_2mggIXLv28bAUJGVajGo=.3e363e99-71d1-41ba-a0a1-3ae6966b97d0@github.com>

On Sat, 13 Feb 2021 05:01:17 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261351: Create implementation for NSAccessibilityRadioButton protocol

This pull request has now been integrated.

Changeset: 6badd22e
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6badd22e
Stats:     77 lines in 3 files changed: 76 ins; 0 del; 1 mod

8261351: Create implementation for NSAccessibilityRadioButton protocol

Reviewed-by: pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/2561

From prr at openjdk.java.net  Mon Feb 15 19:54:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Feb 2021 19:54:42 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
Message-ID: <qZMqki-8fLk4zL6SJaAjPJSwYylZZh07mLCDNb5mQNY=.3de5a494-a83a-4eae-bd85-65f094ab8f51@github.com>

On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Changes requested by gziemski (Committer).
>
> I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a startup time regression with the Metal rendering pipeline, so I dug a bit and here is what I found using Xcode startup profiler:
> 
> Here is the OpenGL pipeline:
> <img width="1904" alt="OpenGL" src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png">
> 
> 
> Here is the Metal pipeline:
> <img width="1904" alt="Metal" src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png">
> 
> If I read the results correctly, there is a weird 330ms time gap in the case of the Metal pipeline where nothing is done and it looks like the culprit is `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable`
> 
> The OpenGL pipeline gets blocked only for 83ms in `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo`
> 
> I would advice that we take a closer look at why 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so long, and optimize it, or cache the results, so the next VM instance can skip it if needed (assuming the call doesn't end up initializing the native Metal or something like that), still worth taking a look.
> 
> I would also recommend that you adopt Xcode and its Instruments profiler tools for future work. Please let me know if you need help in this area.
> 
> I only scratched the surface here and I think that there is plenty of profiling that can be done to investigate the startup time regression further.

> Thanks @gerard-ziemski for taking a detailed look at this.
> We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).

Hi Gerard, expecting a process and parsing its output is definitely not ideal and that's why there's this open bug.
One thing that is under consideration is to equate >= 10.14  with Metal is available since as of 10.14 macOS won't install if a system does not support metal. We have no compelling reason to support metal on earlier releases anyway .. those are either already unsupported or barely supported and OGL will always be available there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Mon Feb 15 20:23:41 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 15 Feb 2021 20:23:41 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v7]
In-Reply-To: <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <7P4ONRc-p2HS2DoBlbidUzQZtzgOa632LawOTz3pxls=.ad7a30cd-70e5-4035-978b-d4befaff523a@github.com>
 <38dK4vpwf0Kc0iIlzHaJ2QfmR6ikKeW_0_R3WKxeqJ0=.2acfe519-1300-4b43-a46c-a272dc130f9c@github.com>
 <I2QaAsY9WjRMsgbH95n4JoWmsI2RTZlJrAAwx6LvJaQ=.f67633e5-89e4-4de5-9691-70f9ed563e3a@github.com>
Message-ID: <YpJSeGOgUIRnuYAwAYmA5Y4woo-cIi67Gnr6p6Hkabo=.9afa1997-c3a2-4791-a85e-ee5795978116@github.com>

On Mon, 15 Feb 2021 18:30:51 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Changes requested by gziemski (Committer).
>
> I took a look at https://bugs.openjdk.java.net/browse/JDK-8261408 and noticed a startup time regression with the Metal rendering pipeline, so I dug a bit and here is what I found using Xcode startup profiler:
> 
> Here is the OpenGL pipeline:
> <img width="1904" alt="OpenGL" src="https://user-images.githubusercontent.com/63425797/107981859-8efb4780-6f88-11eb-849a-385c29f3ff6f.png">
> 
> 
> Here is the Metal pipeline:
> <img width="1904" alt="Metal" src="https://user-images.githubusercontent.com/63425797/107981882-9ae70980-6f88-11eb-9b73-d1bd19dfa07f.png">
> 
> If I read the results correctly, there is a weird 330ms time gap in the case of the Metal pipeline where nothing is done and it looks like the culprit is `Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable`
> 
> The OpenGL pipeline gets blocked only for 83ms in `Java_sun_java2d_opengl_CGLGraphicsConfig_getCGLConfigInfo`
> 
> I would advice that we take a closer look at why 'Java_sun_java2d_metal_MTLGraphicsConfig_isMetalFrameworkAvailable' takes so long, and optimize it, or cache the results, so the next VM instance can skip it if needed (assuming the call doesn't end up initializing the native Metal or something like that), still worth taking a look.
> 
> I would also recommend that you adopt Xcode and its Instruments profiler tools for future work. Please let me know if you need help in this area.
> 
> I only scratched the surface here and I think that there is plenty of profiling that can be done to investigate the startup time regression further.

> > Thanks @gerard-ziemski for taking a detailed look at this.
> > We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).
> 
> Hi Gerard, expecting a process and parsing its output is definitely not ideal and that's why there's this open bug.
> One thing that is under consideration is to equate >= 10.14 with Metal is available since as of 10.14 macOS won't install if a system does not support metal. We have no compelling reason to support metal on earlier releases anyway .. those are either already unsupported or barely supported and OGL will always be available there.

I did not know that there already was a bug covering this issue.

Your idea seems reasonable.

More than just focusing on this immediate issue, however, I was hoping to raise the point of us starting adopting profiling tools to analyze our code (memory utilization, leaks, cpu/gpu profiling etc). A new feature that brings 10% benefit, but uses 50% more resources for example would probably not be a good investment. And to figure that we need to relay on some good tools and Xcode provides some.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From gziemski at openjdk.java.net  Mon Feb 15 20:54:48 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Mon, 15 Feb 2021 20:54:48 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v8]
In-Reply-To: <alfbii4uc4NQLgHs1q26Yrjxx5bmtDWoEDjA2BUAfW8=.9264bf96-068b-4864-80e9-c83d16d5c53e@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <alfbii4uc4NQLgHs1q26Yrjxx5bmtDWoEDjA2BUAfW8=.9264bf96-068b-4864-80e9-c83d16d5c53e@github.com>
Message-ID: <leagyBpC8sFaseUwCyKmkNrgCXw1dgUhmyTBv_Z4U_Q=.116fddf2-5136-48ec-90a8-285db988d19d@github.com>

On Mon, 15 Feb 2021 06:24:13 GMT, Ajit Ghaisas <aghaisas at openjdk.org> wrote:

>> **Description :**
>> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
>> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
>> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
>> 
>> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
>> 
>> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
>> 
>> **Testing :**
>> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
>> 
>> **Note to reviewers :**
>> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
>> 
>> 2) To apply and test this PR - 
>> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
>> 
>> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598
>
> Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
> 
>  - Lanai PR#191 - 8261705 - jdv
>  - Lanai PR#190 - 8261706 - jdv
>  - Lanai PR#189 - 8261712 - avu
>  - Lanai PR#187 - 8261704 - jdv
>  - Lanai PR#186 - 8261638 - avu
>  - Lanai PR#185 - 8261632 - jdv
>  - Lanai PR#184 - 8261620 - aghaisas
>  - Lanai PR#182 - 8261547 - psadhukhan
>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>  - Lanai PR#181 - 8261143 - aghaisas
>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/827ab648...7b0b0dc4

Marked as reviewed by gziemski (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From prr at openjdk.java.net  Mon Feb 15 20:59:44 2021
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 15 Feb 2021 20:59:44 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v8]
In-Reply-To: <leagyBpC8sFaseUwCyKmkNrgCXw1dgUhmyTBv_Z4U_Q=.116fddf2-5136-48ec-90a8-285db988d19d@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
 <alfbii4uc4NQLgHs1q26Yrjxx5bmtDWoEDjA2BUAfW8=.9264bf96-068b-4864-80e9-c83d16d5c53e@github.com>
 <leagyBpC8sFaseUwCyKmkNrgCXw1dgUhmyTBv_Z4U_Q=.116fddf2-5136-48ec-90a8-285db988d19d@github.com>
Message-ID: <g4FJx3rAG66rHxxlEzRf4q2pC_wVp7Qtw9jh5qsQ9JQ=.8f0637ea-e874-4b1b-b255-103527b2964c@github.com>

On Mon, 15 Feb 2021 20:52:09 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:
>> 
>>  - Lanai PR#191 - 8261705 - jdv
>>  - Lanai PR#190 - 8261706 - jdv
>>  - Lanai PR#189 - 8261712 - avu
>>  - Lanai PR#187 - 8261704 - jdv
>>  - Lanai PR#186 - 8261638 - avu
>>  - Lanai PR#185 - 8261632 - jdv
>>  - Lanai PR#184 - 8261620 - aghaisas
>>  - Lanai PR#182 - 8261547 - psadhukhan
>>  - Merge branch 'master' into 8260931_lanai_JEP_branch
>>  - Lanai PR#181 - 8261143 - aghaisas
>>  - ... and 10 more: https://git.openjdk.java.net/jdk/compare/c8554bef...7b0b0dc4
>
> Marked as reviewed by gziemski (Committer).

> > > Thanks @gerard-ziemski for taking a detailed look at this.
> > > We do have an open bug to address this. Please refer [JDK-8259825](https://bugs.openjdk.java.net/browse/JDK-8259825).
> > 
> > 
> > Hi Gerard, expecting a process and parsing its output is definitely not ideal and that's why there's this open bug.
> > One thing that is under consideration is to equate >= 10.14 with Metal is available since as of 10.14 macOS won't install if a system does not support metal. We have no compelling reason to support metal on earlier releases anyway .. those are either already unsupported or barely supported and OGL will always be available there.
> 
> I did not know that there already was a bug covering this issue.
> 
> Your idea seems reasonable.
> 
> More than just focusing on this immediate issue, however, I was hoping to raise the point of us starting adopting profiling tools to analyze our code (memory utilization, leaks, cpu/gpu profiling etc). A new feature that brings 10% benefit, but uses 50% more resources for example would probably not be a good investment. And to figure that we need to relay on some good tools and Xcode provides some.

There were actually tasks to do profiling of the memory footprint and look for leaks. We did not think it possible to be able to assert "Metal must use less memory than OpenGL" or dig into tiny differences but it was intended to find the big issues. See https://bugs.openjdk.java.net/browse/JDK-8237856
@prsadhuk maybe able to say how much of it was doing using Xcode.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2403

From kizune at openjdk.java.net  Wed Feb 17 18:36:50 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 17 Feb 2021 18:36:50 GMT
Subject: <AWT Dev> RFR: 8261350: Create implementation for
 NSAccessibilityCheckBox protocol peer
Message-ID: <AP_kfJDRkQSDfLpDDexWukYgdGYZ6PsB-5VL8eK2_ro=.f78828b6-ba66-4086-a41c-7c4a737cafeb@github.com>

8261350: Create implementation for NSAccessibilityCheckBox protocol peer

-------------

Commit messages:
 - 8261350: Create implementation for NSAccessibilityCheckBox protocol peer

Changes: https://git.openjdk.java.net/jdk/pull/2613/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2613&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261350
  Stats: 11 lines in 5 files changed: 1 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2613.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2613/head:pull/2613

PR: https://git.openjdk.java.net/jdk/pull/2613

From duke at openjdk.java.net  Thu Feb 18 05:25:41 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 18 Feb 2021 05:25:41 GMT
Subject: <AWT Dev> Withdrawn: 8251854: [macosx] Java forces the use of
 discrete GPU
In-Reply-To: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
References: <Nf052gV_cPeWE9lYgIOeus5BZZXi_Pc-BFICzqLVO4A=.8fb05764-e448-4c82-91a6-cecbb2ed6b2e@github.com>
Message-ID: <Uqfuy5C4lJjPOpJtSoob4RICrIO445gl0ROFNGPvjjE=.15418ab1-9caa-4713-9fc6-479f071f8c07@github.com>

On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is a review request for the bug particularly fixed some time ago:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html
> 
> In that review request it was found that the old fix does not work well in all cases, see:
> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html
> 
> The current fix updates an embedded plist.info, so the java will not require
> discrete graphics by default, same as for any other applications. 
> 
> The discrete card will be used:
>  1. If macOS decided to enable it for some reason
>  2. If the java app sets/uses a full-screen window
>  3. If the user disable "automatic graphics switching" in the system preferences
>  4. If an external monitor is connected to the laptop
> 
> In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds.
> 
> 
> Note that the new "metal" pipeline also does not require discrete graphics.
> 
> The documentation for NSSupportsAutomaticGraphicsSwitching:
> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching
> 
> I'll create a release note after approval.
> 
> Performance numbers:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html
> Old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1139

From pbansal at openjdk.java.net  Fri Feb 19 13:08:40 2021
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 19 Feb 2021 13:08:40 GMT
Subject: <AWT Dev> RFR: 8261350: Create implementation for
 NSAccessibilityCheckBox protocol peer
In-Reply-To: <AP_kfJDRkQSDfLpDDexWukYgdGYZ6PsB-5VL8eK2_ro=.f78828b6-ba66-4086-a41c-7c4a737cafeb@github.com>
References: <AP_kfJDRkQSDfLpDDexWukYgdGYZ6PsB-5VL8eK2_ro=.f78828b6-ba66-4086-a41c-7c4a737cafeb@github.com>
Message-ID: <2bhfXGMkGLOepsuQBRv3tMTNs5fGv3TWuYphgQQb_0c=.65b14c4b-1d45-40e9-9407-e97f91e31547@github.com>

On Wed, 17 Feb 2021 18:31:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261350: Create implementation for NSAccessibilityCheckBox protocol peer

Marked as reviewed by pbansal (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2613

From kizune at openjdk.java.net  Sat Feb 20 05:42:40 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Sat, 20 Feb 2021 05:42:40 GMT
Subject: <AWT Dev> Integrated: 8261350: Create implementation for
 NSAccessibilityCheckBox protocol peer
In-Reply-To: <AP_kfJDRkQSDfLpDDexWukYgdGYZ6PsB-5VL8eK2_ro=.f78828b6-ba66-4086-a41c-7c4a737cafeb@github.com>
References: <AP_kfJDRkQSDfLpDDexWukYgdGYZ6PsB-5VL8eK2_ro=.f78828b6-ba66-4086-a41c-7c4a737cafeb@github.com>
Message-ID: <8pbOmuhYrMAZOuYodi_Cd9sy_6rj8N-4ts_PxFnb3YM=.0aa217d6-2e29-419c-83d0-06b7dc50844c@github.com>

On Wed, 17 Feb 2021 18:31:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> 8261350: Create implementation for NSAccessibilityCheckBox protocol peer

This pull request has now been integrated.

Changeset: 2b00367e
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2b00367e
Stats:     11 lines in 5 files changed: 1 ins; 4 del; 6 mod

8261350: Create implementation for NSAccessibilityCheckBox protocol peer

Reviewed-by: pbansal

-------------

PR: https://git.openjdk.java.net/jdk/pull/2613

From aghaisas at openjdk.java.net  Sun Feb 21 18:39:23 2021
From: aghaisas at openjdk.java.net (Ajit Ghaisas)
Date: Sun, 21 Feb 2021 18:39:23 GMT
Subject: <AWT Dev> RFR: 8260931: Implement JEP 382: New macOS Rendering
 Pipeline [v9]
In-Reply-To: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
References: <lPQccQHbaF1OdHK1x3nnNgWsXczfZFCYdGKAuSJzfGU=.d475d9b8-1b89-4d9e-b192-7574fdc93e72@github.com>
Message-ID: <5wwMZghKIzcuLmBQR0IchoAw36UtdItsa0ZvJ2mKrGo=.478ceb31-c7e1-411e-8b75-afa724b0572c@github.com>

> **Description :**
> This is the implementation of [JEP 382 : New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8238361)
> It implements a Java 2D internal rendering pipeline for macOS using the Apple Metal API.
> The entire work on this was done under [OpenJDK Project - Lanai](http://openjdk.java.net/projects/lanai/)
> 
> We iterated through several Early Access (EA) builds and have reached a stage where it is ready to be integrated to openjdk/jdk. The latest EA build is available at - https://jdk.java.net/lanai/
> 
> A new option -Dsun.java2d.metal=true | True needs to be used to use this pipeline.
> 
> **Testing :**
> This implementation has been tested with the tests present at - [Test Plan for JEP 382: New macOS Rendering Pipeline](https://bugs.openjdk.java.net/browse/JDK-8251396)
> 
> **Note to reviewers :**
> 1) Default rendering pipeline on macOS has not been changed by this PR. OpenGL still stays as the default rendering pipeline and Metal rendering pipeline is optional to choose.
> 
> 2) To apply and test this PR - 
> To enable the metal pipeline you must specify on command line -Dsun.java2d.metal=true (No message will be printed in this case) or -Dsun.java2d.metal=True (A message indicating Metal rendering pipeline is enabled gets printed)
> 
> 3) Review comments (including some preliminary informal review comments) are tracked with JBS issues - https://bugs.openjdk.java.net/issues/?filter=40598

Ajit Ghaisas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 29 additional commits since the last revision:

 - Lanai PR#199 - 8262091 - aghaisas
 - Lanai PR#198 - 8261646 - avu
 - Lanai PR#197 - 8261960 - jdv
 - Lanai PR#196 - 8260715 - avu
 - Lanai PR#195 - 8261908 - jdv
 - Lanai PR#194 - 8261703 - jdv
 - Lanai PR#193 - 8261734 - avu
 - Lanai PR#192 - 8261789 - aghaisas
 - Merge branch 'master' into 8260931_lanai_JEP_branch
 - Lanai PR#191 - 8261705 - jdv
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/b17c91cb...614be056

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2403/files
  - new: https://git.openjdk.java.net/jdk/pull/2403/files/7b0b0dc4..614be056

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2403&range=07-08

  Stats: 11833 lines in 292 files changed: 8413 ins; 2170 del; 1250 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2403.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2403/head:pull/2403

PR: https://git.openjdk.java.net/jdk/pull/2403

From serb at openjdk.java.net  Tue Feb 23 15:23:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Feb 2021 15:23:54 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <h8azogOoMJNjjuE1Foqob6JKY4_20yY1rZ_t7j0rmDI=.face8167-4841-4470-98b0-00c9aebb1448@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy
> 
> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

The changes look fine, I'll run the tests.

src/java.desktop/windows/classes/sun/print/Win32PrintJob.java line 435:

> 433:             if (mDestination != null) { // if destination attribute is set
> 434:                 try {
> 435:                     Files.copy(instream, Path.of(mDestination));

Looks like the new code unlike the old one will throw an exception if the file is exists already. WIll it affect the printing functionality?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 23 15:23:54 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Feb 2021 15:23:54 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to new
 convinient methods in java.desktop
Message-ID: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>

Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
1. java.io.InputStream#readAllBytes
2. java.io.InputStream#transferTo
3. java.nio.file.Files#copy

Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

-------------

Commit messages:
 - [PATCH] Refactor manual I/O stream copying to new convenient methods in java.desktop
 - [PATCH] Refactor I/O stream copying to use java.io.InputStream.transferTo in java.desktop

Changes: https://git.openjdk.java.net/jdk/pull/1856/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1856&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262161
  Stats: 134 lines in 11 files changed: 3 ins; 102 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1856/head:pull/1856

PR: https://git.openjdk.java.net/jdk/pull/1856

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 23 15:23:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Feb 2021 15:23:55 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <h8azogOoMJNjjuE1Foqob6JKY4_20yY1rZ_t7j0rmDI=.face8167-4841-4470-98b0-00c9aebb1448@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
 <h8azogOoMJNjjuE1Foqob6JKY4_20yY1rZ_t7j0rmDI=.face8167-4841-4470-98b0-00c9aebb1448@github.com>
Message-ID: <inC9D7UdcLMS940dgUNoCEw9NuHxjFVVrDMVIx-MY0A=.2396e96b-a550-45c9-9036-b7705609d3c8@github.com>

On Sun, 3 Jan 2021 03:08:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>> 
>> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272
>
> src/java.desktop/windows/classes/sun/print/Win32PrintJob.java line 435:
> 
>> 433:             if (mDestination != null) { // if destination attribute is set
>> 434:                 try {
>> 435:                     Files.copy(instream, Path.of(mDestination));
> 
> Looks like the new code unlike the old one will throw an exception if the file is exists already. WIll it affect the printing functionality?

good catch! Added `StandardCopyOption.REPLACE_EXISTING` to preserve behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From serb at openjdk.java.net  Tue Feb 23 15:23:54 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Feb 2021 15:23:54 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <h8azogOoMJNjjuE1Foqob6JKY4_20yY1rZ_t7j0rmDI=.face8167-4841-4470-98b0-00c9aebb1448@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
 <h8azogOoMJNjjuE1Foqob6JKY4_20yY1rZ_t7j0rmDI=.face8167-4841-4470-98b0-00c9aebb1448@github.com>
Message-ID: <RODtj4KbZLN99dWWRZ7WsepGE0WlCzc5J6f6dql918Y=.4066a888-d75b-4447-bdf5-06d44ce2131c@github.com>

On Mon, 22 Feb 2021 18:38:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>> 
>> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272
>
> The changes look fine, I'll run the tests.

I have filed https://bugs.openjdk.java.net/browse/JDK-8262161

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From psadhukhan at openjdk.java.net  Tue Feb 23 15:49:44 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 23 Feb 2021 15:49:44 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <UttuZLHmHMQV4jkEEfeXQz91QIlWAXCbwg4BHocMfq8=.91bc5fb8-b85d-4aa6-93be-dea79846e885@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy
> 
> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

src/java.desktop/windows/classes/sun/print/Win32PrintJob.java line 436:

> 434:             if (mDestination != null) { // if destination attribute is set
> 435:                 try {
> 436:                     Files.copy(instream, Path.of(mDestination), StandardCopyOption.REPLACE_EXISTING);

Don't we need to close the instream in finally block?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 23 16:46:48 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Feb 2021 16:46:48 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <UttuZLHmHMQV4jkEEfeXQz91QIlWAXCbwg4BHocMfq8=.91bc5fb8-b85d-4aa6-93be-dea79846e885@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
 <UttuZLHmHMQV4jkEEfeXQz91QIlWAXCbwg4BHocMfq8=.91bc5fb8-b85d-4aa6-93be-dea79846e885@github.com>
Message-ID: <Q-Dp2PT3AU61UJeChalX-1psXfVitlZVEB4Us_FnkTk=.40b29b0c-13f4-4610-ac14-5a04d57dae22@github.com>

On Tue, 23 Feb 2021 15:47:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>> 
>> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272
>
> src/java.desktop/windows/classes/sun/print/Win32PrintJob.java line 436:
> 
>> 434:             if (mDestination != null) { // if destination attribute is set
>> 435:                 try {
>> 436:                     Files.copy(instream, Path.of(mDestination), StandardCopyOption.REPLACE_EXISTING);
> 
> Don't we need to close the instream in finally block?

It will be closed in `notifyEvent(PrintJobEvent.JOB_FAILED);` -> `closeDataStreams` in case of IOException.
And there shouldn't be any other kinds of exceptions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From serb at openjdk.java.net  Tue Feb 23 22:33:40 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 23 Feb 2021 22:33:40 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v2]
In-Reply-To: <u97YI2k6WfnWLOosYdPFnRSvD-7L0PaZnndjiCqiSBA=.27d5b15e-bc77-483c-84be-e40982f5d21f@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
 <r_29BJgyyg89MweV8NPnu88uwEdzGCblNRFZjbfZnuk=.a7dbfe78-c89c-4ab2-83f9-1a0b1569f306@github.com>
 <y08RKlQcqHLRrERSQLmJ05dQS2SqKXFJN8mclidulAE=.83938572-9f2b-44ff-84da-24e0be1c146c@github.com>
 <u97YI2k6WfnWLOosYdPFnRSvD-7L0PaZnndjiCqiSBA=.27d5b15e-bc77-483c-84be-e40982f5d21f@github.com>
Message-ID: <8eIfz7elBoX4w0libPGOMw4ARrRnGR5oC9pOMnr3wQM=.c7976577-8864-41e4-b91f-ce0ede794826@github.com>

On Fri, 12 Feb 2021 21:53:05 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/X11/XDnDDropTargetProtocol.java line 618:
>> 
>>> 616:             try {
>>> 617:                 for (int i = 0; i < gdslen; i++) {
>>> 618:                     long screenRoot = XlibWrapper.RootWindow(display, i);
>> 
>> I am not sure this will work in the multi-monitors configuration when the screen is split across a few monitors(when Xinerama is enabled for example). In such a configuration, only one root window and only one X11 screen exist. And the index of the GraphicsDevice is the index of the "virtual" monitor, so you cannot pass this index to the "XlibWrapper.RootWindow".
>> 
>> A few questions:
>> * Are you sure that to scale the x/y in the device space you need to find where the pointer is located? And not where the x/y coordinates are located themselves?
>> * Did you try to iterate over the devices->downscale the bounds of each GD to the device scale and upscale the x/y using the selected device. Such utility method can be added to the SunGraphicsEnvironment
>
> Sergey, thanks for the hint! Hope I understand you right. Please, review my changes!
> 
> I decided to do necessary scaling in place and not to add an utility method to SunGraphicsEnvironment due to the following doubts: 
> the methods from SunGraphicsEnvironment can be called from different OS and I'm going to use GraphicsConfig::getBounds() but I see that the Unix implementation includes downscaling (X11GraphicsConfig::getBounds(), src/java.desktop/unix/classes/sun/awt/X11GraphicsConfig.java) and the Windows one is not (Win32GraphicsConfig::getBounds(), src/java.desktop/windows/classes/sun/awt/Win32GraphicsConfig.java); 
> so for Unix I need upscaling before checking the point position but for Windows it is not needed. 
> Please, correct me if I'm wrong!
> 
> Concerning my previous implementation based on the cursor position, would you be so kind to take a look at XMouseInfoPeer::fillPointWithCoords(..) (src/java.desktop/unix/classes/sun/awt/X11/XMouseInfoPeer.java) in order to check whether it should be also fixed?

Yes, I think the fillPointWithCoords is also broken.

I'll run the tests for this change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1907

From prr at openjdk.java.net  Thu Feb 25 22:20:42 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Feb 2021 22:20:42 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <eniXGnIegGbn5FUZh57MJ7SrIVwI2neTC-Xu1k0LvgU=.6da35b30-2139-4248-9fe2-4d5e9bcbe78d@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy
> 
> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

src/java.desktop/unix/classes/sun/print/UnixPrintJob.java line 601:

> 599:             try (BufferedInputStream bin = new BufferedInputStream(instream);
> 600:                  BufferedOutputStream bout = new BufferedOutputStream(output)) {
> 601:                 bin.transferTo(bout);

https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream)

This method does not close either stream.

---

So this doesn't look right.

src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java line 990:

> 988:             AudioInputStream stream = AudioSystem.getAudioInputStream(
> 989:                     audioformat, (AudioInputStream)sample.getData());
> 990:             stream.transferTo(data_chunk);

Are all these audio streams buffered ? transferTo docs don't say anything in terms of guarantees of what API they call. If it is unbuffered and it just calls read(byte) over and over it would be really slow.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From serb at openjdk.java.net  Thu Feb 25 22:59:42 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 25 Feb 2021 22:59:42 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <cln_Eq1igadNLEi0PVinQ1wNOm4MKVSoz5WvQFIwOa4=.f228c5c5-d795-4e6e-b163-f6d259300c10@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy
> 
> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

The direct replacement of the old API by the new one looks fine. The tests are green.

-------------

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1856

From jjg at openjdk.java.net  Thu Feb 25 23:19:51 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 25 Feb 2021 23:19:51 GMT
Subject: <AWT Dev> RFR: JDK-8262420: typo: @implnote in java.desktop module
Message-ID: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>

Please review some doc changes in `java.awt.TrayIcon`.

Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:

1. Fix the name of the `@implNote` tag
2. Remove the redundant `<p>` before the `@implNote` tag
3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

-------------

Commit messages:
 - JDK-8262420: typo: @implnote in java.desktop module

Changes: https://git.openjdk.java.net/jdk/pull/2735/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2735&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262420
  Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2735.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2735/head:pull/2735

PR: https://git.openjdk.java.net/jdk/pull/2735

From iris at openjdk.java.net  Thu Feb 25 23:27:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Feb 2021 23:27:39 GMT
Subject: <AWT Dev> RFR: JDK-8262420: typo: @implnote in java.desktop
 module
In-Reply-To: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
References: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
Message-ID: <OAp1q4tSEWD02XjoI6uDfPBK-3ra-eEmxLLdRrqqFt0=.535a539a-83f9-4efa-918d-d184d75b43a7@github.com>

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `<p>` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2735

From prr at openjdk.java.net  Fri Feb 26 00:44:40 2021
From: prr at openjdk.java.net (Phil Race)
Date: Fri, 26 Feb 2021 00:44:40 GMT
Subject: <AWT Dev> RFR: JDK-8262420: typo: @implnote in java.desktop
 module
In-Reply-To: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
References: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
Message-ID: <IdnTvZAL9r5OZTKHNtR6pHtI5Lnaag8WifTMPjEWJmw=.5185d480-7eee-4b4e-a449-04e79d88e1b7@github.com>

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `<p>` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2735

From azvegint at openjdk.java.net  Fri Feb 26 00:49:42 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 26 Feb 2021 00:49:42 GMT
Subject: <AWT Dev> RFR: JDK-8262420: typo: @implnote in java.desktop
 module
In-Reply-To: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
References: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
Message-ID: <W9MHo8Itwpf4tfTdkanHPLXEWZx1dpAPMs1Jq8_bOik=.f82c56dc-d7bf-4c1f-8c39-01694a0af799@github.com>

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `<p>` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2735

From aivanov at openjdk.java.net  Fri Feb 26 12:24:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 26 Feb 2021 12:24:40 GMT
Subject: <AWT Dev> RFR: JDK-8262420: typo: @implnote in java.desktop
 module
In-Reply-To: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
References: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
Message-ID: <RLlel4-PxcTnWQc0ZZvhoL79NYGeE0Qx8QVupqX3pXY=.cc6de29d-d994-4775-a2d0-9142ab4f57e0@github.com>

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `<p>` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2735

From mbaesken at openjdk.java.net  Fri Feb 26 14:24:54 2021
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Fri, 26 Feb 2021 14:24:54 GMT
Subject: <AWT Dev> RFR: JDK-8262461: handle wcstombsdmp return value
 correctly in unix awt_InputMethod.c
Message-ID: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>

The function wcstombsdmp is called at a few places in awt_InputMethod.c.
This function needs checking of a NULL return value and freeing of the memory allocated by this function. However this is missing at one place in the file.

-------------

Commit messages:
 - JDK-8262461

Changes: https://git.openjdk.java.net/jdk/pull/2747/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2747&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262461
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2747.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2747/head:pull/2747

PR: https://git.openjdk.java.net/jdk/pull/2747

From jjg at openjdk.java.net  Fri Feb 26 15:14:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 26 Feb 2021 15:14:39 GMT
Subject: <AWT Dev> Integrated: JDK-8262420: typo: @implnote in java.desktop
 module
In-Reply-To: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
References: <DMOKpgMoJT_4K-oFL4YnA8OHBR1oW0pVzak6iSQu8s4=.dafe8077-5858-4e93-8478-386cc408cf45@github.com>
Message-ID: <LlyBnPMZrqxAX69PRe4uQAQB5Pw6e9v2Zsb-PEy4PqM=.469da555-067b-4342-9a09-ca72880529da@github.com>

On Thu, 25 Feb 2021 23:15:03 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some doc changes in `java.awt.TrayIcon`.
> 
> Note, the fix is more than the 1-character fix for the typo detected by doclint. The changes are:
> 
> 1. Fix the name of the `@implNote` tag
> 2. Remove the redundant `<p>` before the `@implNote` tag
> 3. Move the `@implNote` tag and its immediate content to after the following paragraph, (beginning _See the ..._) which was originally part of the main description, and does not appear that it should be part of the implementation note.

This pull request has now been integrated.

Changeset: 67b9e5a6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67b9e5a6
Stats:     7 lines in 1 file changed: 2 ins; 3 del; 2 mod

8262420: typo: @implnote in java.desktop module

Reviewed-by: iris, prr, azvegint, aivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/2735

From psadhukhan at openjdk.java.net  Fri Feb 26 15:40:38 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Fri, 26 Feb 2021 15:40:38 GMT
Subject: <AWT Dev> RFR: JDK-8262461: handle wcstombsdmp return value
 correctly in unix awt_InputMethod.c
In-Reply-To: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
References: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
Message-ID: <UYeNmDVIFQFjnPokQSHiTBfxqLTijgxEe6sZ7yGbKUw=.aa83f7c1-ed7e-48d1-8ca2-8920566c361d@github.com>

On Fri, 26 Feb 2021 14:19:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function wcstombsdmp is called at a few places in awt_InputMethod.c.
> This function needs checking of a NULL return value and freeing of the memory allocated by this function. However this is missing at one place in the file.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2747

From azvegint at openjdk.java.net  Fri Feb 26 16:14:40 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Fri, 26 Feb 2021 16:14:40 GMT
Subject: <AWT Dev> RFR: JDK-8262461: handle wcstombsdmp return value
 correctly in unix awt_InputMethod.c
In-Reply-To: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
References: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
Message-ID: <Za--fw6rX1I05UE2Q-TTLQ_wkGZfkBQK1A85lpmKoOU=.6de7e05a-bbe9-42a2-b5e4-de8ff5361c87@github.com>

On Fri, 26 Feb 2021 14:19:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function wcstombsdmp is called at a few places in awt_InputMethod.c.
> This function needs checking of a NULL return value and freeing of the memory allocated by this function. However this is missing at one place in the file.

Marked as reviewed by azvegint (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2747

From aivanov at openjdk.java.net  Fri Feb 26 17:35:40 2021
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Fri, 26 Feb 2021 17:35:40 GMT
Subject: <AWT Dev> RFR: JDK-8262461: handle wcstombsdmp return value
 correctly in unix awt_InputMethod.c
In-Reply-To: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
References: <MrWD8WUY47YyXKzldNZ3LyYNlVRBs4kVicYcpPIn_Qk=.2a2a47d9-d85d-42fc-addb-4e1da757948d@github.com>
Message-ID: <9Kr8T00BF8TNObsIGwTTVyhlEylLBa3fmOYeEgulk88=.67ab154b-7e2d-4c7b-b25b-35476984c25e@github.com>

On Fri, 26 Feb 2021 14:19:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The function wcstombsdmp is called at a few places in awt_InputMethod.c.
> This function needs checking of a NULL return value and freeing of the memory allocated by this function. However this is missing at one place in the file.

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2747

From alexsch at openjdk.java.net  Fri Feb 26 19:45:57 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 26 Feb 2021 19:45:57 GMT
Subject: <AWT Dev> RFR: 8262470: Printed GlyphVector outline with low DPI
 has bad quality on Windows
Message-ID: <SXgjmlvR91f-zY-0Ku7RZ59ucQoT7tltvb1XVb1Hyrk=.88afc47c-e3b1-4836-af1b-e44063efd2be@github.com>

Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows.
The GDI system used for text printing on Windows accepts only integer path coordinates.
Rounding GlyphVector outline coordinates leads to distorted printed text.

The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page".

The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo()  methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down.

The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up.

I tried to put wPrinterJob.beginPath()/endPath()  methods around wPrinterJob.moveTo()/lineTo()   in the method WPathGraphics.deviceDrawLine()  but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape.

The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method.
The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() .

The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix.

There are two failed automated tests which fail without the fix as well:
java/awt/print/PrinterJob/GlyphPositions.java 
java/awt/print/PrinterJob/PSQuestionMark.java

The following manual tests have issues on my system:
- `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static"

- `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons.

- `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html


- `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain  print/pass/fail buttons and it is not possible to close the window.

- The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message:
java/awt/print/Dialog/DialogOrient.java
java/awt/print/Dialog/DialogType.java
java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java
java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java
java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java
java/awt/print/PrinterJob/PageDialogTest.java
java/awt/print/PrinterJob/PageRanges.java
java/awt/print/PrinterJob/PageRangesDlgTest.java
java/awt/print/PrinterJob/PrintGlyphVectorTest.java
java/awt/print/PrinterJob/PrintLatinCJKTest.java
java/awt/print/PrinterJob/PrintTextTest.java
java/awt/print/PrinterJob/SwingUIText.java
java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java
java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java
java/awt/PrintJob/SaveDialogTitleTest.java

-------------

Commit messages:
 - 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows

Changes: https://git.openjdk.java.net/jdk/pull/2756/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2756&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262470
  Stats: 725 lines in 5 files changed: 722 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2756.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2756/head:pull/2756

PR: https://git.openjdk.java.net/jdk/pull/2756

From serb at openjdk.java.net  Fri Feb 26 20:31:45 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 26 Feb 2021 20:31:45 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <eniXGnIegGbn5FUZh57MJ7SrIVwI2neTC-Xu1k0LvgU=.6da35b30-2139-4248-9fe2-4d5e9bcbe78d@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
 <eniXGnIegGbn5FUZh57MJ7SrIVwI2neTC-Xu1k0LvgU=.6da35b30-2139-4248-9fe2-4d5e9bcbe78d@github.com>
Message-ID: <vw_YMaMjjhWCP72u3Q6pI7BNOOe7nSTolVuOYDjP27w=.fcd999e1-d2bd-4c7b-bd28-1776760fef01@github.com>

On Wed, 24 Feb 2021 20:48:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
>> 1. java.io.InputStream#readAllBytes
>> 2. java.io.InputStream#transferTo
>> 3. java.nio.file.Files#copy
>> 
>> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272
>
> src/java.desktop/unix/classes/sun/print/UnixPrintJob.java line 601:
> 
>> 599:             try (BufferedInputStream bin = new BufferedInputStream(instream);
>> 600:                  BufferedOutputStream bout = new BufferedOutputStream(output)) {
>> 601:                 bin.transferTo(bout);
> 
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream)
> 
> This method does not close either stream.
> 
> ---
> 
> So this doesn't look right.

The method itself does not close it, but the "try-with-res" around it should.

> src/java.desktop/share/classes/com/sun/media/sound/DLSSoundbank.java line 990:
> 
>> 988:             AudioInputStream stream = AudioSystem.getAudioInputStream(
>> 989:                     audioformat, (AudioInputStream)sample.getData());
>> 990:             stream.transferTo(data_chunk);
> 
> Are all these audio streams buffered ? transferTo docs don't say anything in terms of guarantees of what API they call. If it is unbuffered and it just calls read(byte) over and over it would be really slow.

It read the data in chunks of "8192" bytes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From prr at openjdk.java.net  Sat Feb 27 00:48:38 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 27 Feb 2021 00:48:38 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <vw_YMaMjjhWCP72u3Q6pI7BNOOe7nSTolVuOYDjP27w=.fcd999e1-d2bd-4c7b-bd28-1776760fef01@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
 <eniXGnIegGbn5FUZh57MJ7SrIVwI2neTC-Xu1k0LvgU=.6da35b30-2139-4248-9fe2-4d5e9bcbe78d@github.com>
 <vw_YMaMjjhWCP72u3Q6pI7BNOOe7nSTolVuOYDjP27w=.fcd999e1-d2bd-4c7b-bd28-1776760fef01@github.com>
Message-ID: <1Jdv9_gjRYFjbjuWFkqZslSZAMKt0iwaPaXQ4mRhaNI=.4dc06a05-aa8f-4523-851f-565ead337814@github.com>

On Fri, 26 Feb 2021 20:21:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/print/UnixPrintJob.java line 601:
>> 
>>> 599:             try (BufferedInputStream bin = new BufferedInputStream(instream);
>>> 600:                  BufferedOutputStream bout = new BufferedOutputStream(output)) {
>>> 601:                 bin.transferTo(bout);
>> 
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/InputStream.html#transferTo(java.io.OutputStream)
>> 
>> This method does not close either stream.
>> 
>> ---
>> 
>> So this doesn't look right.
>
> The method itself does not close it, but the "try-with-res" around it should.

ah yes

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From prr at openjdk.java.net  Sat Feb 27 00:48:37 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 27 Feb 2021 00:48:37 GMT
Subject: <AWT Dev> RFR: 8262161 Refactor manual I/O stream copying to
 new convinient methods in java.desktop
In-Reply-To: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
References: <ufDL14NgeugRfIkjQ4_Uz8z-xcT0eQ40GuPEERyOPhY=.70440aa1-c77e-462a-9e48-2ccf00044875@github.com>
Message-ID: <fPlt_EPdXAncEkMSJXwZXYWlUXnc8rUF1siWVex4IKk=.8b46bbc1-392e-4a10-b4dc-9f6d00439a46@github.com>

On Mon, 21 Dec 2020 07:54:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Cleanup code to use new handy methods in `java.io.InputStream`/`java.nio.file.Files` instead of manual stream copy:
> 1. java.io.InputStream#readAllBytes
> 2. java.io.InputStream#transferTo
> 3. java.nio.file.Files#copy
> 
> Similar issue - https://bugs.openjdk.java.net/browse/JDK-8080272

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1856

From serb at openjdk.java.net  Sat Feb 27 01:21:41 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 27 Feb 2021 01:21:41 GMT
Subject: <AWT Dev> RFR: 8257414: Drag n Drop target area is wrong on
 high DPI systems [v3]
In-Reply-To: <59jhaSZ-ekCP39Y_qcaSCTVo8VRCmtjnvWxj1i_ZS9k=.b882bde5-40c6-4da6-8287-5937ea7d4fa1@github.com>
References: <fQNJqOlcj0huN2eRDRLb4BsxQf9wCW8Y3cjt134Kjc8=.6f8b2556-6dc8-425f-b45d-2e9e2d873f34@github.com>
 <59jhaSZ-ekCP39Y_qcaSCTVo8VRCmtjnvWxj1i_ZS9k=.b882bde5-40c6-4da6-8287-5937ea7d4fa1@github.com>
Message-ID: <zJzNZTxSTkw_gGip1saIrKejBEFQuMXlko1NdNCc0WI=.28e0af3c-7f97-4ca6-95c1-50574885400e@github.com>

On Fri, 12 Feb 2021 21:43:56 GMT, Olga Mikhaltsova <omikhaltcova at openjdk.org> wrote:

>> Please, review this small fix for drag-n-drop on Linux with HiDPI turned on!
>> 
>> This bug is due to the following reason: while scaling Java recalculates resolution (W x H) according to sun.java2d.uiScale (W/SCALE x H/SCALE) and works inside these new coordinates but at the same time the events, that come from the system, continue reporting positions in the old coordinates (W x H).
>> 
>> The idea of the suggested fix is in division of coordinates on the scale when they come from the system to Java and multiplying them on the scale when they go back from Java to the system. It is similar to processing events from mouse and buttons. 
>> 
>> Testing is quite complicated because for reproducing this bug the following conditions should be met:
>> 1.	HiDPI is turned on
>> 2.	sun.java2d.uiScale.enabled = true and sun.java2d.uiScale != 100%
>> 3.	the source of drag-n-drop is non-java application
>> 
>> The step-by-step guide how to reproduce this bug is added to https://bugs.openjdk.java.net/browse/JDK-8257414.
>
> Olga Mikhaltsova has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257414: Drag n Drop target area is wrong on high DPI systems

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1907