Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

2021-06-01 Thread Sergey Bylokhov 
On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov  wrote:

> Set black color for underlying window background to perform correct blending 
> operations in metal with window surface destination

I guess the bug happens when we blit our "layer" surface to the window? So 
there is no way to set a kind of "src" composite? Will it help if you "clear" 
the layer to some color(white?) and then immediately blit the content on top of 
it?

-

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

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Sergey Bylokhov 
On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev 
 wrote:

> This commit introduces a new client property xawt.mwm_decor_title 
> implementing JDK-8267307. The property can be set prior to showing a window 
> or after the window has been displayed, in which case the window will have to 
> be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 
> window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 
> (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
> decorate with anything, even borders or resize handles. With 
> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
> take as "decorate with only a border", thus effectively removing the window's 
> title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
> where it did not have any effect; these two WMs have limited respected for 
> the "decorations" bits of the _MOTIF_WM_HINTS window property.

Please check that the test code added in the JDK-8265005 can be adapted to 
verify this fix as well.

-

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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Joe Wang 
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 
>> 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system 
>> property is now "disallow", most of the tests calling 
>> `System.setSecurityManager()` need to launched with 
>> `-Djava.security.manager=allow`. This is covered in a different PR at 
>> https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, 
>> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are 
>> reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: 
> https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by joehw (Reviewer).

-

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

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Alexander Zvegintsev 
On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev 
 wrote:

> This commit introduces a new client property xawt.mwm_decor_title 
> implementing JDK-8267307. The property can be set prior to showing a window 
> or after the window has been displayed, in which case the window will have to 
> be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 
> window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 
> (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
> decorate with anything, even borders or resize handles. With 
> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
> take as "decorate with only a border", thus effectively removing the window's 
> title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
> where it did not have any effect; these two WMs have limited respected for 
> the "decorations" bits of the _MOTIF_WM_HINTS window property.

Marked as reviewed by azvegint (Reviewer).

-

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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Alan Bateman 
On Tue, 1 Jun 2021 15:21:33 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 
>> 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system 
>> property is now "disallow", most of the tests calling 
>> `System.setSecurityManager()` need to launched with 
>> `-Djava.security.manager=allow`. This is covered in a different PR at 
>> https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, 
>> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are 
>> reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 11 commits:
> 
>  - merge from master
>  - rename setSecurityManagerDirect to implSetSecurityManager
>  - default behavior reverted to allow
>  - move one annotation to new method
>  - merge from master, two files removed, one needs merge
>  - keep only one systemProperty tag
>  - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
>  - feedback from Sean, Phil and Alan
>  - add supresswarnings annotations automatically
>  - manual change before automatic annotating
>  - ... and 1 more: 
> https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

Marked as reviewed by alanb (Reviewer).

-

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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v8]

2021-06-01 Thread Weijun Wang 
> Please review this implementation of [JEP 
> 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. 
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system 
> property is now "disallow", most of the tests calling 
> `System.setSecurityManager()` need to launched with 
> `-Djava.security.manager=allow`. This is covered in a different PR at 
> https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, 
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are 
> reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 11 commits:

 - merge from master
 - rename setSecurityManagerDirect to implSetSecurityManager
 - default behavior reverted to allow
 - move one annotation to new method
 - merge from master, two files removed, one needs merge
 - keep only one systemProperty tag
 - fixing awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java
 - feedback from Sean, Phil and Alan
 - add supresswarnings annotations automatically
 - manual change before automatic annotating
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/74b70a56...ea2c4b48

-

Changes: https://git.openjdk.java.net/jdk/pull/4073/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk=4073=07
  Stats: 2132 lines in 826 files changed: 1997 ins; 20 del; 115 mod
  Patch: https://git.openjdk.java.net/jdk/pull/4073.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/4073/head:pull/4073

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

Re: RFR: 8266079: Lanai: AlphaComposite shows differences on Metal compared to OpenGL

2021-06-01 Thread Alan Snyder 
Could the flashing problem be related to the timing problem described in 
JDK-8209329 ?

I have noticed occasional red flashes using Metal, which I suspect are caused 
by trying to render uninitialized data.
(I’m guessing that the red is a debugging aid provided by Apple. Previously, 
they used yellow.)


> On May 29, 2021, at 12:22 AM, Alexey Ushakov  wrote:
> 
> On Wed, 26 May 2021 13:49:24 GMT, Alexey Ushakov  wrote:
> 
>> Set black color for underlying window background to perform correct blending 
>> operations in metal with window surface destination
> 
> Looks like the second option won't work because the result of blending will 
> still be mixed with the NSWindow background color. Also, I tried several more 
> approaches (Use only rgb blending, make the layer opaque). They helped to 
> resolve the test issues but caused regressions in other areas (SwingSet2 tree 
> for example). So, now I think that the only working solution is presented 
> here (to set the background color of the window) 
> 
>> Yes, looks like we have the flashing problem back. It seems more serious 
>> than this particular bug.
>> We have two options here:
>> 
>> 1. accept this behavior for metal (It would be not a problem if we implement 
>>  JDK-8265445)
>> 2. reimplement all the composing operations via shaders instead of using 
>> metal blending rules
> 
> -
> 
> PR: https://git.openjdk.java.net/jdk/pull/4206
>

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v7]

2021-06-01 Thread Weijun Wang 
> Please review this implementation of [JEP 
> 411](https://openjdk.java.net/jeps/411).
> 
> The code change is divided into 3 commits. Please review them one by one.
> 
> 1. 
> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>  The essential change for this JEP, including the `@Deprecate` annotations 
> and spec change. It also update the default value of the 
> `java.security.manager` system property to "disallow", and necessary test 
> change following this update.
> 2. 
> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>  Manual changes to several files so that the next commit can be generated 
> programatically.
> 3. 
> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>  Automatic changes to other source files to avoid javac warnings on 
> deprecation for removal
> 
> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
> generated programmatically, see the comment below for more details. If you 
> are only interested in a portion of the 3rd commit and would like to review 
> it as a separate file, please comment here and I'll generate an individual 
> webrev.
> 
> Due to the size of this PR, no attempt is made to update copyright years for 
> any file to minimize unnecessary merge conflict.
> 
> Furthermore, since the default value of `java.security.manager` system 
> property is now "disallow", most of the tests calling 
> `System.setSecurityManager()` need to launched with 
> `-Djava.security.manager=allow`. This is covered in a different PR at 
> https://github.com/openjdk/jdk/pull/4071.
> 
> Update: the deprecation annotations and javadoc tags, build, compiler, 
> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are 
> reviewed. Rest are 2d, awt, beans, sound, and swing.

Weijun Wang has updated the pull request incrementally with one additional 
commit since the last revision:

  rename setSecurityManagerDirect to implSetSecurityManager

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/4073/files
  - new: https://git.openjdk.java.net/jdk/pull/4073/files/8fd09c39..926e4b9a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk=4073=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk=4073=05-06

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

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

Re: RFR: 8266459: Implement JEP 411: Deprecate the Security Manager for Removal [v6]

2021-06-01 Thread Alan Bateman 
On Mon, 31 May 2021 15:02:57 GMT, Weijun Wang  wrote:

>> Please review this implementation of [JEP 
>> 411](https://openjdk.java.net/jeps/411).
>> 
>> The code change is divided into 3 commits. Please review them one by one.
>> 
>> 1. 
>> https://github.com/openjdk/jdk/commit/576161d15423f58281e384174d28c9f9be7941a1
>>  The essential change for this JEP, including the `@Deprecate` annotations 
>> and spec change. It also update the default value of the 
>> `java.security.manager` system property to "disallow", and necessary test 
>> change following this update.
>> 2. 
>> https://github.com/openjdk/jdk/commit/26a54a835e9f84aa528740a7c5c35d07355a8a66
>>  Manual changes to several files so that the next commit can be generated 
>> programatically.
>> 3. 
>> https://github.com/openjdk/jdk/commit/eb6c566ff9207974a03a53335e0e697cffcf0950
>>  Automatic changes to other source files to avoid javac warnings on 
>> deprecation for removal
>> 
>> The 1st and 2nd commits should be reviewed carefully. The 3rd one is 
>> generated programmatically, see the comment below for more details. If you 
>> are only interested in a portion of the 3rd commit and would like to review 
>> it as a separate file, please comment here and I'll generate an individual 
>> webrev.
>> 
>> Due to the size of this PR, no attempt is made to update copyright years for 
>> any file to minimize unnecessary merge conflict.
>> 
>> Furthermore, since the default value of `java.security.manager` system 
>> property is now "disallow", most of the tests calling 
>> `System.setSecurityManager()` need to launched with 
>> `-Djava.security.manager=allow`. This is covered in a different PR at 
>> https://github.com/openjdk/jdk/pull/4071.
>> 
>> Update: the deprecation annotations and javadoc tags, build, compiler, 
>> core-libs, hotspot, i18n, jmx, net, nio, security, and serviceability are 
>> reviewed. Rest are 2d, awt, beans, sound, and swing.
>
> Weijun Wang has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   default behavior reverted to allow

System.setSecurityManagerDirect looks a bit ugly now. Can this be renamed to 
implSetSecurityManager and avoid the line break in the  middle of the 
declaration?

The usage of System.err usage in setSecurityManager also needs to be 
re-examined as this will run arbitrary code when System.err can be changed. To 
fix this will require capturing the stream at startup (as was done with the 
illegal access logger). It's okay to integrate with what you have for the first 
push and we can fix this issue with System.err when the warning message is 
changed to the intended message.

-

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

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Maxim Kartashev 
On Tue, 1 Jun 2021 11:38:49 GMT, Alexander Zvegintsev  
wrote:

> This fix most likely will require a CSR

There already is one linked from the enhancement: 
[JDK-8267308](https://bugs.openjdk.java.net/browse/JDK-8267308)

-

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

Re: RFR: 8267307: Introduce new client property for XAWT: xawt.mwm_decor_title

2021-06-01 Thread Alexander Zvegintsev 
On Wed, 19 May 2021 10:23:01 GMT, Maxim Kartashev 
 wrote:

> This commit introduces a new client property xawt.mwm_decor_title 
> implementing JDK-8267307. The property can be set prior to showing a window 
> or after the window has been displayed, in which case the window will have to 
> be hidden/shown (re-mapped) for the property to take effect.
> 
> The general idea is to provide control over the "decorations" part of the X11 
> window property called _MOTIF_WM_HINTS. Those "decoration" bits are set to 1 
> (XWindowAttributesData.AWT_DECOR_ALL) to show all the decorations or 0 
> (XWindowAttributesData.AWT_DECOR_NONE) to ask the window manager (WM) not to 
> decorate with anything, even borders or resize handles. With 
> xawt.mwm_decor_title property set to "true", this commit adds the ability to 
> set the bits to 2 (XWindowAttributesData.AWT_DECOR_BORDER), which some WMs 
> take as "decorate with only a border", thus effectively removing the window's 
> title bar, but still leaving the resize capability.
> 
> This feature was tested and works correctly on "vanilla" Ubuntu 20.04 with 
> the "GNOME Shell" window manager. It was also tested with Xfwm4 and KDE, 
> where it did not have any effect; these two WMs have limited respected for 
> the "decorations" bits of the _MOTIF_WM_HINTS window property.

This fix most likely will require a CSR

test/jdk/java/awt/Window/WindowTitleVisibleTest/WindowTitleVisibleTestLinuxGnome.java
 line 111:

> 109: private void captureTitleBarNotVisible() {
> 110: runSwing( () -> {
> 111: titleBarImageNotVisible = 
> robot.createScreenCapture(titleBarBounds);

`createScreenCapture` does not require to be called on EDT.

-

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