Suggestion:

    * Example: 

src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 207:

> 205:      * Returns the icon of the specified size used to display this shell folder.
> 206:      *
> 207:      * @param size size of the icon > 0(Valid range: 1 to 256)

Suggestion:

     * @param size size of the icon > 0 (Valid range: 1 to 256)

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1035:

> 1033:                         new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB);
> 1034:                 img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize);
> 1035:                 return img;

There are cases where the size of the buffered image is different from the requested size. It could affect the layout
because it breaks the assumption that the returned image has the requested size but it may be larger.

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1105:

> 1103:                                     bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2);
> 1104:                                     newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE
> 1105:                                             : SMALL_ICON_SIZE, bothIcons);

I propose to refactor this code into a separate method which always fetches small and large icon and puts into a
corresponding cache.

However, I still think there's not much value in getting smaller icon size in addition to larger one. Or does it
provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with
scaling of 100%?

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1163:

> 1161:
> 1162:                     multiResolutionIcon.put(s, newIcon);
> 1163:                     if (size < 8 || size > 256) {

Suggestion:

                    if (size < MIN_QUALITY_ICON || size > MAX_QUALITY_ICON) {

src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java line 414:

> 412:                 if (i >= 0) {
> 413:                     return Win32ShellFolder2.getShell32Icon(i,
> 414:                          key.startsWith("shell32LargeIcon ")?LARGE_ICON_SIZE : SMALL_ICON_SIZE);

Suggestion:

                         key.startsWith("shell32LargeIcon ") ? LARGE_ICON_SIZE : SMALL_ICON_SIZE);

test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 69:

> 67:             }
> 68:         }
> 69:     }

Does it make sense to check that the icon is a multi-resolution image with the expected sizes?

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

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

From serb at openjdk.java.net  Fri Oct  9 01:59:31 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 9 Oct 2020 01:59:31 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v2]
In-Reply-To: 
References: 
Message-ID: 

> This bug easily reproduced by the test in question on the dual video card systems
> when the metal pipeline is active. But it is possible to reproduce it in the OGL
> pipeline as well, but it is required some additional steps.
> 
> Problem description:
>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
> important feature of this CGraphicsEnvironment is to invalidate the old devices and
> map them to the new devices. For example, if the user got a reference to the device,
> and this device was removed then this reference will refer to the main screen.
> 
> The problem in the current implementation arise when the system has two video cards:
>   1 The user get some GraphicsDevice
>   2 The user sets the full-screen window for this device
>   3 The user change screen resolution for this device
>   4 The resolution of the screen is not changed ->> BUG.
> 
> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
> to switch to the discrete video card, but it does not report the old device(integrated VC)
> as removed, because actually no screens were removed.
> 
> Since it was not reported as removed we did not invalidate it and did not map it to the
> new device ->> request to change the screen resolution at step 3 send to some non existed
> deviceID.
> 
> As a fix I suggest to change this current logic:
>   - Invalidate devices reported by macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
> 
> To this logic:
>   - Ignore devices reported by the macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
>   - Check that the main device is in the list of all NEW devices
>   - Invalidate all OLD devices which are not in the list of NEW devices
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update CGraphicsEnvironment.java

  Make sure the main display is in the list of all displays.
  Prevent duplicate main screen if the switch has happened.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/554/files
  - new: https://git.openjdk.java.net/jdk/pull/554/files/5dc06c0e..93ebb049

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

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

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

From serb at openjdk.java.net  Fri Oct  9 02:03:34 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 9 Oct 2020 02:03:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v3]
In-Reply-To: 
References: 
Message-ID: <_8O97miWQf1ulqbrnj8qATQozm0rrA5BSP792whsdqk=.4ca83076-422b-44a0-8d5a-74f9bebf429b@github.com>

> This bug easily reproduced by the test in question on the dual video card systems
> when the metal pipeline is active. But it is possible to reproduce it in the OGL
> pipeline as well, but it is required some additional steps.
> 
> Problem description:
>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
> important feature of this CGraphicsEnvironment is to invalidate the old devices and
> map them to the new devices. For example, if the user got a reference to the device,
> and this device was removed then this reference will refer to the main screen.
> 
> The problem in the current implementation arise when the system has two video cards:
>   1 The user get some GraphicsDevice
>   2 The user sets the full-screen window for this device
>   3 The user change screen resolution for this device
>   4 The resolution of the screen is not changed ->> BUG.
> 
> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
> to switch to the discrete video card, but it does not report the old device(integrated VC)
> as removed, because actually no screens were removed.
> 
> Since it was not reported as removed we did not invalidate it and did not map it to the
> new device ->> request to change the screen resolution at step 3 send to some non existed
> deviceID.
> 
> As a fix I suggest to change this current logic:
>   - Invalidate devices reported by macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
> 
> To this logic:
>   - Ignore devices reported by the macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
>   - Check that the main device is in the list of all NEW devices
>   - Invalidate all OLD devices which are not in the list of NEW devices
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html

Sergey Bylokhov 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:

 - Merge branch 'master' into JDK-8252133
 - Update CGraphicsEnvironment.java

   Make sure the main display is in the list of all displays.
   Prevent duplicate main screen if the switch has happened.
 - Merge branch 'master' into JDK-8252133
 - Update CycleDMImage.java
 - Merge branch 'master' into JDK-8252133
 - 8252133: The java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal pipeline is active

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/554/files
  - new: https://git.openjdk.java.net/jdk/pull/554/files/93ebb049..a38ef0ef

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

  Stats: 2246 lines in 89 files changed: 1365 ins; 632 del; 249 mod
  Patch: https://git.openjdk.java.net/jdk/pull/554.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/554/head:pull/554

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

From serb at openjdk.java.net  Fri Oct  9 05:42:31 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 9 Oct 2020 05:42:31 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v4]
In-Reply-To: 
References: 
Message-ID: 

> This bug easily reproduced by the test in question on the dual video card systems
> when the metal pipeline is active. But it is possible to reproduce it in the OGL
> pipeline as well, but it is required some additional steps.
> 
> Problem description:
>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
> important feature of this CGraphicsEnvironment is to invalidate the old devices and
> map them to the new devices. For example, if the user got a reference to the device,
> and this device was removed then this reference will refer to the main screen.
> 
> The problem in the current implementation arise when the system has two video cards:
>   1 The user get some GraphicsDevice
>   2 The user sets the full-screen window for this device
>   3 The user change screen resolution for this device
>   4 The resolution of the screen is not changed ->> BUG.
> 
> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
> to switch to the discrete video card, but it does not report the old device(integrated VC)
> as removed, because actually no screens were removed.
> 
> Since it was not reported as removed we did not invalidate it and did not map it to the
> new device ->> request to change the screen resolution at step 3 send to some non existed
> deviceID.
> 
> As a fix I suggest to change this current logic:
>   - Invalidate devices reported by macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
> 
> To this logic:
>   - Ignore devices reported by the macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
>   - Check that the main device is in the list of all NEW devices
>   - Invalidate all OLD devices which are not in the list of NEW devices
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Update CGraphicsEnvironment.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/554/files
  - new: https://git.openjdk.java.net/jdk/pull/554/files/a38ef0ef..0b81a0fe

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

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

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

From serb at openjdk.java.net  Mon Oct 12 18:35:28 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 12 Oct 2020 18:35:28 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254608: Update the classes in the
 java.awt.color package
Message-ID: 

- The spec  for ICC_ProfileRGB.getGamma(int) and ICC_ProfileRGB.getTRC(int) is updated
 - Two additional tests are added to cover some basic specified functionality
 - Some code in these classes was simplified/cleaned
 - Some common code is extracted to the separate methods.

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

Commit messages:
 - Update ColorSpace.java
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/612/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=612&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254608
  Stats: 389 lines in 6 files changed: 284 ins; 77 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/612.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/612/head:pull/612

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

From philip.race at oracle.com  Tue Oct 13 16:08:53 2020
From: philip.race at oracle.com (Philip Race)
Date: Tue, 13 Oct 2020 09:08:53 -0700
Subject: [OpenJDK 2D-Dev] EA6 build of Project Lanai (Java 2D Metal
 rendering pipeline for macOS) is now posted
In-Reply-To: <5F63F79F.7000702@oracle.com>
References: <5F63F79F.7000702@oracle.com>
Message-ID: <5F85D115.5010008@oracle.com>

I am a bit slow in sending out the announcement, but
https://jdk.java.net/lanai/ is now hosting the EA 6 build of Lanai

    EA 6 Build 16-lanai+2-229 (2020/10/4)

Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues.

EA 6 contains the following new bug fixes relative to EA 5

  * 8253931: Lanai: MTLTexturePool refactoring

  * 8253840: Lanai - MTLClip.beginShapeClip method uses a larger
    temporary buffer than needed

  * 8252790: Lanai: Refactor RenderPerfTest to run single test by name

  * 8253657: Lanai: Refactor MTLTexturePool - getTexture

  * 8251475: sun/java2d/pipe/hw/RSLAPITest/RSLAPITest.java fails with
    metal pipeline 
  * 8246194: Performance of Mix.Balls decreases when Rendering Quality
    option is Selected 
  * 8252796: Lanai: Shape clip test artifacts on MacBook Air 2020

  * 8252499: UI text of application with metal pipeline is lost when
    another application is launched with OpenGL pipeline

  * 8253301: Lanai: Memory leak in MTLContext code

  * 8253260: Fix whitespace errors in .m and .metal files in lanai repo

  * 8252795: Lanai: Refactor native implementation of MTLPaint

  * 8251023: Clipping of Image doesnt work when Alpha composite is
    enabled in J2DDemo 
  * 8252880: Image operations are not working with metal

  * 8252895: Black background in SwingSet2 in Nimbus LAF

  * 8252949: Shape clip should use identity transform for drawing clip
    spans 

-phil.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From robilad at openjdk.java.net  Wed Oct 14 17:45:19 2020
From: robilad at openjdk.java.net (Dalibor Topic)
Date: Wed, 14 Oct 2020 17:45:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
Message-ID: 

On Thu, 8 Oct 2020 12:57:29 GMT, Andrii Rodionov  wrote:

> The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024

Hi, please send the details whose OCA you are covered under to  Dalibor.topic at oracle.com so that I can verify your
account. Thanks!

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

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

From github.com+1538227+arodionov at openjdk.java.net  Wed Oct 14 17:45:19 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Wed, 14 Oct 2020 17:45:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
Message-ID: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024

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

Commit messages:
 - 8254024: Enhance native libs for AWT and Swing to work with GraalVM Native Image

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

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

From github.com+1538227+arodionov at openjdk.java.net  Wed Oct 14 17:45:20 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Wed, 14 Oct 2020 17:45:20 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Fri, 9 Oct 2020 18:31:50 GMT, Andrii Rodionov  wrote:

>> Hi, please send the details whose OCA you are covered under to  Dalibor.topic at oracle.com so that I can verify your
>> account. Thanks!
>
> @robilad Hi Dalibor! Have sent you email with details.
> Thanks!

@bobvandette Could you please join to the review?

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

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

From github.com+1538227+arodionov at openjdk.java.net  Wed Oct 14 17:45:19 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Wed, 14 Oct 2020 17:45:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Fri, 9 Oct 2020 17:20:38 GMT, Dalibor Topic  wrote:

>> The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024
>
> Hi, please send the details whose OCA you are covered under to  Dalibor.topic at oracle.com so that I can verify your
> account. Thanks!

@robilad Hi Dalibor! Have sent you email with details.
Thanks!

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

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

From prr at openjdk.java.net  Wed Oct 14 17:59:13 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 14 Oct 2020 17:59:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Wed, 14 Oct 2020 17:41:57 GMT, Andrii Rodionov  wrote:

>> @robilad Hi Dalibor! Have sent you email with details.
>> Thanks!
>
> @bobvandette Could you please join to the review?

It is generally not expected for such a proposed change to pop up out of nowhere from someone who is a new contributor
without prior discussion and so forth.
I have no idea where this change is coming from, why we would want it,  and how it is expected to be supported and you
have provided zero explanation of any of it in the PR. I think you need to start by explaining the big picture, and
what you expect to do with this and how you are guaranteeing to support it and ensure it breaks NOTHING else. At all.
And then we could also use some technical details on what you perceive is needed and why this resolives it.
Also is this "everything" ?

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

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

From bobv at openjdk.java.net  Wed Oct 14 18:26:22 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Wed, 14 Oct 2020 18:26:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
Message-ID: 

On Thu, 8 Oct 2020 12:57:29 GMT, Andrii Rodionov  wrote:

> The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024

src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 820:

> 818:
> 819: JNIEXPORT void JNICALL
> 820: Java_sun_xawt_motif_XsessionWMcommand(JNIEnv *env, jobject this,

I'm not sure if this entrypoint is ever accessed externally in a normal JDK.  To be safe, can you make both name
changes conditional on STATIC_BUILD?

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

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

From bobv at openjdk.java.net  Wed Oct 14 18:29:17 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Wed, 14 Oct 2020 18:29:17 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Wed, 14 Oct 2020 17:56:34 GMT, Phil Race  wrote:

> It is generally not expected for such a proposed change to pop up out of nowhere from someone who is a new contributor
> without prior discussion and so forth.
> I have no idea where this change is coming from, why we would want it, and how it is expected to be supported and you
> have provided zero explanation of any of it in the PR. I think you need to start by explaining the big picture, and
> what you expect to do with this and how you are guaranteeing to support it and ensure it breaks NOTHING else. At all.
> And then we could also use some technical details on what you perceive is needed and why this resolives it.
> Also is this "everything" ?

I've been coaching @arodionov through this change.  This fix extends the work I did to allow a Java program to be
created using all static libraries.

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

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

From prr at openjdk.java.net  Wed Oct 14 18:34:15 2020
From: prr at openjdk.java.net (Phil Race)
Date: Wed, 14 Oct 2020 18:34:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Wed, 14 Oct 2020 18:26:35 GMT, Bob Vandette  wrote:

>> It is generally not expected for such a proposed change to pop up out of nowhere from someone who is a new contributor
>> without prior discussion and so forth.
>> I have no idea where this change is coming from, why we would want it,  and how it is expected to be supported and you
>> have provided zero explanation of any of it in the PR. I think you need to start by explaining the big picture, and
>> what you expect to do with this and how you are guaranteeing to support it and ensure it breaks NOTHING else. At all.
>> And then we could also use some technical details on what you perceive is needed and why this resolives it.
>> Also is this "everything" ?
>
>> It is generally not expected for such a proposed change to pop up out of nowhere from someone who is a new contributor
>> without prior discussion and so forth.
>> I have no idea where this change is coming from, why we would want it, and how it is expected to be supported and you
>> have provided zero explanation of any of it in the PR. I think you need to start by explaining the big picture, and
>> what you expect to do with this and how you are guaranteeing to support it and ensure it breaks NOTHING else. At all.
>> And then we could also use some technical details on what you perceive is needed and why this resolives it.
>> Also is this "everything" ?
> 
> I've been coaching @arodionov through this change.  This fix extends the work I did to allow a Java program to be
> created using all static libraries.  This PR fixes issues where there are multiply defined symbols in libawt, the
> headless and xawt toolkits when linked into a single executable.  It also solves the problem where dlsym doesn't work
> for non shared libraries.

Sorry I am not familiar with that work. Please provide more info.

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

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

From bobv at openjdk.java.net  Wed Oct 14 18:57:15 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Wed, 14 Oct 2020 18:57:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: 

On Wed, 14 Oct 2020 18:31:28 GMT, Phil Race  wrote:

> Sorry I am not familiar with that work. Please provide more info.

Here's the JEP for the work done in JDK8 to allow libraries to be built and used statically.

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

Here's the changes done to allow a Mac build to be done fully statically.

http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/55573c377d64

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

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

From serb at openjdk.java.net  Wed Oct 14 19:41:22 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 14 Oct 2020 19:41:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254788: Dead code in the
 sun.java2d.xr.XRPMBlitLoops$XrSwToPMBlit
Message-ID: 

The XrSwToPMBlit is a blit which is used as a direct(unscaled) blit of the image in the memory to the pixmap. It tries
to optimize the SrcOver composite in case of an opaque source image and use Src instead:

        if (CompositeType.SrcOverNoEa.equals(comp) && (src.getTransparency() == Transparency.OPAQUE)) {
            Blit opaqueSwToSurfaceBlit = Blit.getFromCache(src.getSurfaceType(), CompositeType.SrcNoEa, dst.getSurfaceType());
            opaqueSwToSurfaceBlit.Blit(src, dst, comp, clip, sx, sy, dx, dy, w, h);
        } else {

The code above does not work for two reasons:
- The check "CompositeType.SrcOverNoEa.equals(comp)" always fails because the comp is of type
  Composite(AlphaComposite/XORComposite/etc) not a CompositeType
 - This optimisation is applied already in the sun.java2d.pipe.DrawImage#blitSurfaceData:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java#L933

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

Commit messages:
 - Update XRPMBlitLoops.java

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

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

From serb at openjdk.java.net  Thu Oct 15 05:45:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 15 Oct 2020 05:45:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254798: Deprecate for removal an empty
 finalize() methods in java.desktop module
Message-ID: <8pMgbLWwSVWixrMJ0E043-FmgaSQiDic-UkDTmFcfY0=.60b52fe4-d4fe-4b30-999a-69f2696f3156@github.com>

The java.desktop module has a few implementations of the finalize() method which do nothing. We can remove such methods
if the class is not public API, and could mark these methods in the public classes as "forRemoval = true"

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

Commit messages:
 - @SuppressWarnings("removal")
 - Initial fix

Changes: https://git.openjdk.java.net/jdk/pull/675/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=675&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254798
  Stats: 49 lines in 6 files changed: 3 ins; 38 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/675/head:pull/675

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

From github.com+127875+xavery at openjdk.java.net  Thu Oct 15 09:59:16 2020
From: github.com+127875+xavery at openjdk.java.net (Daniel Kamil Kozar)
Date: Thu, 15 Oct 2020 09:59:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs
Message-ID: 

This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows
Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly. I have put
this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html),
which was tentatively accepted by Mr. Sergey Bylokhov.

The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving
notifications from the operating system, as they rely on all the applications in the current clipboard chain processing
clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but
also results in slightly less code needed to support clipboard-related functionality.

As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also
require providing a native application that runs alongside the test and deliberately breaks the keyboard chain,
resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the
old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already
existing functionality is not impacted by this change.

I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated
with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.

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

Commit messages:
 - Use new APIs on Windows for monitoring available clipboard formats

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

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

From github.com+1538227+arodionov at openjdk.java.net  Thu Oct 15 15:57:21 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Thu, 15 Oct 2020 15:57:21 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image [v2]
In-Reply-To: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>
Message-ID: 

> The following PR fixes https://bugs.openjdk.java.net/browse/JDK-8254024

Andrii Rodionov has refreshed the contents of this pull request, and previous commits have been removed. The
incremental views will show differences compared to the previous content of the PR. The pull request contains one new
commit since the last revision:

  8254024: Enhance native libs for AWT and Swing to work with GraalVM Native Image

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/562/files
  - new: https://git.openjdk.java.net/jdk/pull/562/files/fa908d98..65d3e835

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

  Stats: 11 lines in 2 files changed: 9 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/562.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/562/head:pull/562

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

From github.com+1538227+arodionov at openjdk.java.net  Thu Oct 15 16:04:12 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Thu, 15 Oct 2020 16:04:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image [v2]
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: <3VEdkzaKztF4yHgfZlsCYWpSTn_Al60bmSCClRF5czk=.942bc0d9-518c-40a9-b0d0-93d6245ccb14@github.com>

On Wed, 14 Oct 2020 18:23:48 GMT, Bob Vandette  wrote:

>> Andrii Rodionov has refreshed the contents of this pull request, and previous commits have been removed. The
>> incremental views will show differences compared to the previous content of the PR.
>
> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 821:
> 
>> 819: JNIEXPORT void JNICALL
>> 820: Java_sun_xawt_motif_XsessionWMcommand(JNIEnv *env, jobject this,
>> 821:     jobject frame, jstring jcommand)
> 
> I'm not sure if this entrypoint is ever accessed externally in a normal JDK.  To be safe, can you make both name
> changes conditional on STATIC_BUILD?

Have made both names conditional.

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

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

From serb at openjdk.java.net  Thu Oct 15 16:43:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 15 Oct 2020 16:43:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

Message-ID: <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

On Wed, 14 Oct 2020 18:54:07 GMT, Bob Vandette  wrote:

> 
> Here's the JEP for the work done in JDK8 to allow libraries to be built and used statically.

Does it mean that in the case of static-libs both variants of AWT libraries(xawt and headless) will be loaded?
How it is possible to test the current changes?

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

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

From prr at openjdk.java.net  Thu Oct 15 16:57:14 2020
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 15 Oct 2020 16:57:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
Message-ID: 

On Thu, 15 Oct 2020 16:40:12 GMT, Sergey Bylokhov  wrote:

>>> Sorry I am not familiar with that work. Please provide more info.
>> 
>> Here's the JEP for the work done in JDK8 to allow libraries to be built and used statically.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8046168
>> 
>> Here's the changes done to allow a Mac build to be done fully statically.
>> 
>> http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/55573c377d64
>
>> 
>> Here's the JEP for the work done in JDK8 to allow libraries to be built and used statically.
> 
> Does it mean that in the case of static-libs both variants of AWT libraries(xawt and headless) will be loaded?
> How it is possible to test the current changes?

I would have to suppose that isn't possible but it is not clear whether the authors
of the fix are OK with this or not because the PR is very light on background and explanation. Which is a blocker for
me.

I don't get the motivation from the JEP as to how it applies here.
There are two motivations listed
1) For environments that don't support dynamic linking, and that doesn't apply to 64 bit Linux server so we can rule
that out 2) For applications that "want" to statically link. I want a lot of things but wanting it isn't a very well
expressed motivation for something like this.

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

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

From github.com+1538227+arodionov at openjdk.java.net  Thu Oct 15 17:00:15 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Thu, 15 Oct 2020 17:00:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>
Message-ID: 

On Thu, 15 Oct 2020 16:40:12 GMT, Sergey Bylokhov  wrote:

> Does it mean that in the case of static-libs both variants of AWT libraries(xawt and headless) will be loaded?

No, they shouldn't. If this happens it causes duplicate symbol error during linkage phase.
For GraalVM native image we select what library should be linked based on `-Djava.awt.headless` property.

>  How it is possible to test the current changes?

For GraalVM native image, we run JCK tests `api/java_awt` and `api/javax_swing`. Those tests built as a native image.

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

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

From serb at openjdk.java.net  Thu Oct 15 17:14:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 15 Oct 2020 17:14:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

Message-ID: 

On Thu, 15 Oct 2020 16:57:27 GMT, Andrii Rodionov  wrote:

> > How it is possible to test the current changes?
> 
> For GraalVM native image, we run JCK tests `api/java_awt` and `api/javax_swing`. Those tests built as a native image.

I meant some "steps to reproduce" the current bug, and which can be used to verify the current fix.

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

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

From github.com+1538227+arodionov at openjdk.java.net  Thu Oct 15 20:31:15 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Thu, 15 Oct 2020 20:31:15 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

Message-ID: 

On Thu, 15 Oct 2020 17:10:58 GMT, Sergey Bylokhov  wrote:

> > > How it is possible to test the current changes?
> > 
> > 
> > For GraalVM native image, we run JCK tests `api/java_awt` and `api/javax_swing`. Those tests built as a native image.
> 
> I meant some "steps to reproduce" the current bug, and which can be used to verify the current fix.

Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are
the successful tests run.

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

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

From serb at openjdk.java.net  Fri Oct 16 04:52:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 16 Oct 2020 04:52:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

Message-ID: 

On Thu, 15 Oct 2020 20:28:53 GMT, Andrii Rodionov  wrote:

> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are
> the successful tests run.

But what exact steps should be done to reproduce this bug w/o using jck or any external tools? Something like:
 - Clone JDK
 - Build JDK using some specific options.
 - Create some small test case
 - Somehow create the native image
 - Run the app -> boom -> bug is reproduced

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

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

From serb at openjdk.java.net  Fri Oct 16 08:48:14 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 16 Oct 2020 08:48:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254863: Delete code leftover from old fixes
Message-ID: <0kYrD4NOgECoyPSAuT-mvmm3aYQi2EWpBMT75CCwXcE=.2d220413-e99e-4632-9b7b-33661692f386@github.com>

The fix for JDK-4893408 adds a special code to handle the "PYCC.pf" color profile for the "kernel java":
https://bugs.openjdk.java.net/browse/JDK-4893408?focusedCommentId=12284308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12284308
The "kernel java" support was removed in jdk7 in JDK-7016724 but the special code in the ICC_Profile.java still exists.

After the fix for JDK-8175984 a few methods became unused:
 - CMSManager#freeProfile()
 - ProfileDeferralMgr#unregisterDeferral()

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

Commit messages:
 - Update ICC_Profile.java
 - Initial fix

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

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

From pbansal at openjdk.java.net  Fri Oct 16 18:38:07 2020
From: pbansal at openjdk.java.net (Pankaj Bansal)
Date: Fri, 16 Oct 2020 18:38:07 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254798: Deprecate for removal an empty
 finalize() methods in java.desktop module
In-Reply-To: <8pMgbLWwSVWixrMJ0E043-FmgaSQiDic-UkDTmFcfY0=.60b52fe4-d4fe-4b30-999a-69f2696f3156@github.com>
References: <8pMgbLWwSVWixrMJ0E043-FmgaSQiDic-UkDTmFcfY0=.60b52fe4-d4fe-4b30-999a-69f2696f3156@github.com>
Message-ID: 

On Thu, 15 Oct 2020 05:29:42 GMT, Sergey Bylokhov  wrote:

> The java.desktop module has a few implementations of the finalize() method which do nothing. We can remove such methods
> if the class is not public API, and could mark these methods in the public classes as "forRemoval = true"

Marked as reviewed by pbansal (Reviewer).

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

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

From github.com+13527108+azeemjiva at openjdk.java.net  Fri Oct 16 21:14:11 2020
From: github.com+13527108+azeemjiva at openjdk.java.net (Azeem Jiva)
Date: Fri, 16 Oct 2020 21:14:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254863: Delete code leftover from old
 fixes
In-Reply-To: <0kYrD4NOgECoyPSAuT-mvmm3aYQi2EWpBMT75CCwXcE=.2d220413-e99e-4632-9b7b-33661692f386@github.com>
References: <0kYrD4NOgECoyPSAuT-mvmm3aYQi2EWpBMT75CCwXcE=.2d220413-e99e-4632-9b7b-33661692f386@github.com>
Message-ID: 

On Fri, 16 Oct 2020 02:31:09 GMT, Sergey Bylokhov  wrote:

> The fix for JDK-4893408 adds a special code to handle the "PYCC.pf" color profile for the "kernel java":
> https://bugs.openjdk.java.net/browse/JDK-4893408?focusedCommentId=12284308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12284308
> The "kernel java" support was removed in jdk7 in JDK-7016724 but the special code in the ICC_Profile.java still exists.
> 
> After the fix for JDK-8175984 a few methods became unused:
>  - CMSManager#freeProfile()
>  - ProfileDeferralMgr#unregisterDeferral()

Marked as reviewed by AzeemJiva at github.com (no known OpenJDK username).

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

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

From github.com+1538227+arodionov at openjdk.java.net  Fri Oct 16 21:57:18 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Fri, 16 Oct 2020 21:57:18 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

Message-ID: 

On Fri, 16 Oct 2020 04:49:37 GMT, Sergey Bylokhov  wrote:

>>> > > How it is possible to test the current changes?
>>> > 
>>> > 
>>> > For GraalVM native image, we run JCK tests `api/java_awt` and `api/javax_swing`. Those tests built as a native image.
>>> 
>>> I meant some "steps to reproduce" the current bug, and which can be used to verify the current fix.
>> 
>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are
>> the successful tests run.
>
>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are
>> the successful tests run.
> 
> But what exact steps should be done to reproduce this bug w/o using jck or any external tools? Something like:
>  - Clone JDK
>  - Build JDK using some specific options.
>  - Create some small test case
>  - Somehow create the native image
>  - Run the app -> boom -> bug is reproduced

Yes, I understand what you mean.
Unfortunately, I don't know a straightforward way.
Maybe the easiest way to reproduce an error and validate the fix is to download the future version of GraalVM with
AWT/Swing support (hope it will be at the end of October), replace `libawt.a` to its unpatched library version and then
build a native image based on the following code:
        float[] data = new float[]{0.0f, 1.1f, 2.2f, 3.3f, 4.4f, 5.5f, 6.6f, 7.7f, 8.8f};
        Kernel kernel = new Kernel(3, 3, data);
        ConvolveOp op = new ConvolveOp(kernel);

        BufferedImage src = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
        BufferedImage dest = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);

        op.filter(src, dest);
The built image run should throw "Unable to convolve src image" ImagingOpException exception.

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

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

From github.com+1538227+arodionov at openjdk.java.net  Fri Oct 16 22:23:10 2020
From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov)
Date: Fri, 16 Oct 2020 22:23:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and
 Swing to work with GraalVM Native Image
In-Reply-To: 
References: <_0LNyX1J7P2doid6n2xtxCGyr2Q1kDYRahUEUAx6iIE=.4de75e90-e772-4044-a23e-980cf56fa63a@github.com>

 <2hFTjMReXMfiNjTWswTV5EyEA7zFoEIbepsyelAcPeU=.fe56a018-3429-420c-b47f-274a400cc989@github.com>

Message-ID: 

On Fri, 16 Oct 2020 21:54:56 GMT, Andrii Rodionov  wrote:

>>> Actually, we have found this issue during JCK tests execution that was built as a native image. The fix criteria are
>>> the successful tests run.
>> 
>> But what exact steps should be done to reproduce this bug w/o using jck or any external tools? Something like:
>>  - Clone JDK
>>  - Build JDK using some specific options.
>>  - Create some small test case
>>  - Somehow create the native image
>>  - Run the app -> boom -> bug is reproduced
>
> Yes, I understand what you mean.
> Unfortunately, I don't know a straightforward way.
> Maybe the easiest way to reproduce an error and validate the fix is to download the future version of GraalVM with
> AWT/Swing support (hope it will be at the end of October), replace `libawt.a` to its unpatched library version and then
> build a native image based on the following code:
>         float[] data = new float[]{0.0f, 1.1f, 2.2f, 3.3f, 4.4f, 5.5f, 6.6f, 7.7f, 8.8f};
>         Kernel kernel = new Kernel(3, 3, data);
>         ConvolveOp op = new ConvolveOp(kernel);
> 
>         BufferedImage src = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
>         BufferedImage dest = new BufferedImage(10, 10, BufferedImage.TYPE_INT_ARGB);
> 
>         op.filter(src, dest);
> The built image run should throw "Unable to convolve src image" ImagingOpException exception.

In general, the 2 following points should be changed and tested in the static libraries:
- rename conflicting/duplicate symbols in libraries that are linked together
- have a workaround for the functionality implemented via dlopen/dlsym

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

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

From serb at openjdk.java.net  Mon Oct 19 03:15:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 19 Oct 2020 03:15:10 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8254798: Deprecate for removal an
 empty finalize() methods in java.desktop module
In-Reply-To: <8pMgbLWwSVWixrMJ0E043-FmgaSQiDic-UkDTmFcfY0=.60b52fe4-d4fe-4b30-999a-69f2696f3156@github.com>
References: <8pMgbLWwSVWixrMJ0E043-FmgaSQiDic-UkDTmFcfY0=.60b52fe4-d4fe-4b30-999a-69f2696f3156@github.com>
Message-ID: 

On Thu, 15 Oct 2020 05:29:42 GMT, Sergey Bylokhov  wrote:

> The java.desktop module has a few implementations of the finalize() method which do nothing. We can remove such methods
> if the class is not public API, and could mark these methods in the public classes as "forRemoval = true"

This pull request has now been integrated.

Changeset: dd032b7f
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/dd032b7f
Stats:     49 lines in 6 files changed: 3 ins; 38 del; 8 mod

8254798: Deprecate for removal an empty finalize() methods in java.desktop module

Reviewed-by: kcr, pbansal

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

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

From prr at openjdk.java.net  Mon Oct 19 23:44:12 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 19 Oct 2020 23:44:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Oct 2020 05:42:31 GMT, Sergey Bylokhov  wrote:

>> This bug easily reproduced by the test in question on the dual video card systems
>> when the metal pipeline is active. But it is possible to reproduce it in the OGL
>> pipeline as well, but it is required some additional steps.
>> 
>> Problem description:
>>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
>> important feature of this CGraphicsEnvironment is to invalidate the old devices and
>> map them to the new devices. For example, if the user got a reference to the device,
>> and this device was removed then this reference will refer to the main screen.
>> 
>> The problem in the current implementation arise when the system has two video cards:
>>   1 The user get some GraphicsDevice
>>   2 The user sets the full-screen window for this device
>>   3 The user change screen resolution for this device
>>   4 The resolution of the screen is not changed ->> BUG.
>> 
>> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
>> to switch to the discrete video card, but it does not report the old device(integrated VC)
>> as removed, because actually no screens were removed.
>> 
>> Since it was not reported as removed we did not invalidate it and did not map it to the
>> new device ->> request to change the screen resolution at step 3 send to some non existed
>> deviceID.
>> 
>> As a fix I suggest to change this current logic:
>>   - Invalidate devices reported by macOS as removed
>>   - Initialize the main screen
>>   - Initialize all NEW screens
>> 
>> To this logic:
>>   - Ignore devices reported by the macOS as removed
>>   - Initialize the main screen
>>   - Initialize all NEW screens
>>   - Check that the main device is in the list of all NEW devices
>>   - Invalidate all OLD devices which are not in the list of NEW devices
>> 
>> The old review request:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CGraphicsEnvironment.java

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Oct 19 23:45:11 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 19 Oct 2020 23:45:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254788: Dead code in the
 sun.java2d.xr.XRPMBlitLoops$XrSwToPMBlit
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Oct 2020 18:35:15 GMT, Sergey Bylokhov  wrote:

> The XrSwToPMBlit is a blit which is used as a direct(unscaled) blit of the image in the memory to the pixmap. It tries
> to optimize the SrcOver composite in case of an opaque source image and use Src instead:
>         if (CompositeType.SrcOverNoEa.equals(comp) && (src.getTransparency() == Transparency.OPAQUE)) {
>             Blit opaqueSwToSurfaceBlit = Blit.getFromCache(src.getSurfaceType(), CompositeType.SrcNoEa, dst.getSurfaceType());
>             opaqueSwToSurfaceBlit.Blit(src, dst, comp, clip, sx, sy, dx, dy, w, h);
>         } else {
> 
> The code above does not work for two reasons:
> - The check "CompositeType.SrcOverNoEa.equals(comp)" always fails because the comp is of type
>   Composite(AlphaComposite/XORComposite/etc) not a CompositeType
>  - This optimisation is applied already in the sun.java2d.pipe.DrawImage#blitSurfaceData:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java#L933

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Mon Oct 19 23:48:10 2020
From: prr at openjdk.java.net (Phil Race)
Date: Mon, 19 Oct 2020 23:48:10 GMT
Subject: [OpenJDK 2D-Dev] RFR: JDK-8234393: [macos] printing ignores
 printer tray [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 7 Oct 2020 14:30:26 GMT, Vipin Menon  wrote:

>> **Issue**
>> 
>> [https://bugs.openjdk.java.net/browse/JDK-8234393](https://bugs.openjdk.java.net/browse/JDK-8234393)
>> 
>> **Problem**
>> 
>> On a multi tray printer, irrespective of what tray is set, Java always prints from the last tray which is the default.
>
> Vipin Menon has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains two commits:
>  - Adding bugID to testcase
>  - JDK-8234393: [macos] printing ignores printer tray

Marked as reviewed by prr (Reviewer).

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

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

From serb at openjdk.java.net  Tue Oct 20 08:41:19 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 20 Oct 2020 08:41:19 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255043: Incorrectly styled copyright text
Message-ID: 

In some files, the copyright text is styled as a JavaDoc comment.
Most of the affected files are tests, only one product file is affected:
src/java.sql/share/classes/javax/sql/package-info.java

The chenge is trivial:
 - /**
 + /*
    * Copyright (c)

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

Commit messages:
 - Initial fix

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

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

From github.com+17762393+vipinmenon at openjdk.java.net  Tue Oct 20 11:18:11 2020
From: github.com+17762393+vipinmenon at openjdk.java.net (Vipin Menon)
Date: Tue, 20 Oct 2020 11:18:11 GMT
Subject: [OpenJDK 2D-Dev] Integrated: JDK-8234393: [macos] printing ignores
 printer tray
In-Reply-To: 
References: 
Message-ID: 

On Mon, 5 Oct 2020 16:58:06 GMT, Vipin Menon  wrote:

> **Issue**
> 
> [https://bugs.openjdk.java.net/browse/JDK-8234393](https://bugs.openjdk.java.net/browse/JDK-8234393)
> 
> **Problem**
> 
> On a multi tray printer, irrespective of what tray is set, Java always prints from the last tray which is the default.

This pull request has now been integrated.

Changeset: 3ee0380e
Author:    Vipin Menon 
Committer: Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/3ee0380e
Stats:     26 lines in 4 files changed: 20 ins; 0 del; 6 mod

8234393: [macos] printing ignores printer tray

Reviewed-by: psadhukhan, prr

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

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

From dholmes at openjdk.java.net  Tue Oct 20 11:50:12 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 20 Oct 2020 11:50:12 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov  wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Seems trivially fine.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

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

From trebari at openjdk.java.net  Tue Oct 20 14:36:16 2020
From: trebari at openjdk.java.net (Tejpal Rebari)
Date: Tue, 20 Oct 2020 14:36:16 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov  wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Marked as reviewed by trebari (Committer).

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

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

From jdv at openjdk.java.net  Tue Oct 20 15:43:14 2020
From: jdv at openjdk.java.net (Jayathirth D V)
Date: Tue, 20 Oct 2020 15:43:14 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8255043: Incorrectly styled copyright text
In-Reply-To: 
References: 
Message-ID: <3HXa_fWqHw4PKAfkD6oo5xKl8gR5ss7yhfl87HdSuGI=.fd3fa01c-a7a1-4e13-ab60-9852ff93162d@github.com>

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov  wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

Marked as reviewed by jdv (Reviewer).

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

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

From serb at openjdk.java.net  Tue Oct 20 17:38:12 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 20 Oct 2020 17:38:12 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8254788: Dead code in the
 sun.java2d.xr.XRPMBlitLoops$XrSwToPMBlit
In-Reply-To: 
References: 
Message-ID: 

On Wed, 14 Oct 2020 18:35:15 GMT, Sergey Bylokhov  wrote:

> The XrSwToPMBlit is a blit which is used as a direct(unscaled) blit of the image in the memory to the pixmap. It tries
> to optimize the SrcOver composite in case of an opaque source image and use Src instead:
>         if (CompositeType.SrcOverNoEa.equals(comp) && (src.getTransparency() == Transparency.OPAQUE)) {
>             Blit opaqueSwToSurfaceBlit = Blit.getFromCache(src.getSurfaceType(), CompositeType.SrcNoEa, dst.getSurfaceType());
>             opaqueSwToSurfaceBlit.Blit(src, dst, comp, clip, sx, sy, dx, dy, w, h);
>         } else {
> 
> The code above does not work for two reasons:
> - The check "CompositeType.SrcOverNoEa.equals(comp)" always fails because the comp is of type
>   Composite(AlphaComposite/XORComposite/etc) not a CompositeType
>  - This optimisation is applied already in the sun.java2d.pipe.DrawImage#blitSurfaceData:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java#L933

This pull request has now been integrated.

Changeset: 89e54445
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/89e54445
Stats:     15 lines in 1 file changed: 0 ins; 6 del; 9 mod

8254788: Dead code in the sun.java2d.xr.XRPMBlitLoops$XrSwToPMBlit

Reviewed-by: prr

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

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

From kizune at openjdk.java.net  Tue Oct 20 23:46:26 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 20 Oct 2020 23:46:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v4]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 9 Oct 2020 05:42:31 GMT, Sergey Bylokhov  wrote:

>> This bug easily reproduced by the test in question on the dual video card systems
>> when the metal pipeline is active. But it is possible to reproduce it in the OGL
>> pipeline as well, but it is required some additional steps.
>> 
>> Problem description:
>>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
>> important feature of this CGraphicsEnvironment is to invalidate the old devices and
>> map them to the new devices. For example, if the user got a reference to the device,
>> and this device was removed then this reference will refer to the main screen.
>> 
>> The problem in the current implementation arise when the system has two video cards:
>>   1 The user get some GraphicsDevice
>>   2 The user sets the full-screen window for this device
>>   3 The user change screen resolution for this device
>>   4 The resolution of the screen is not changed ->> BUG.
>> 
>> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
>> to switch to the discrete video card, but it does not report the old device(integrated VC)
>> as removed, because actually no screens were removed.
>> 
>> Since it was not reported as removed we did not invalidate it and did not map it to the
>> new device ->> request to change the screen resolution at step 3 send to some non existed
>> deviceID.
>> 
>> As a fix I suggest to change this current logic:
>>   - Invalidate devices reported by macOS as removed
>>   - Initialize the main screen
>>   - Initialize all NEW screens
>> 
>> To this logic:
>>   - Ignore devices reported by the macOS as removed
>>   - Initialize the main screen
>>   - Initialize all NEW screens
>>   - Check that the main device is in the list of all NEW devices
>>   - Invalidate all OLD devices which are not in the list of NEW devices
>> 
>> The old review request:
>> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update CGraphicsEnvironment.java

src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 182:

> 180:         }
> 181:         // fetch the main display again, the old value might be outdated
> 182:         mainDisplayID = getMainDisplayID();

What action since line 162 can trigger changing the getMainDisplayID() outcome?

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

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

From serb at openjdk.java.net  Wed Oct 21 00:22:13 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 21 Oct 2020 00:22:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active [v4]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 20 Oct 2020 23:43:46 GMT, Alexander Zuev  wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update CGraphicsEnvironment.java
>
> src/java.desktop/macosx/classes/sun/awt/CGraphicsEnvironment.java line 182:
> 
>> 180:         }
>> 181:         // fetch the main display again, the old value might be outdated
>> 182:         mainDisplayID = getMainDisplayID();
> 
> What action since line 162 can trigger changing the getMainDisplayID() outcome?

If the main screen is not in the list of screens means that the system monitors were changed in some way after this
method was called and we will get one more notification later.

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

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

From serb at openjdk.java.net  Wed Oct 21 00:22:13 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 21 Oct 2020 00:22:13 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8252133: The
 java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal
 pipeline is active
In-Reply-To: 
References: 
Message-ID: 

On Thu, 8 Oct 2020 04:22:10 GMT, Sergey Bylokhov  wrote:

> This bug easily reproduced by the test in question on the dual video card systems
> when the metal pipeline is active. But it is possible to reproduce it in the OGL
> pipeline as well, but it is required some additional steps.
> 
> Problem description:
>    Our CGraphicsEnvironment maintains the list of active graphics devices. The one
> important feature of this CGraphicsEnvironment is to invalidate the old devices and
> map them to the new devices. For example, if the user got a reference to the device,
> and this device was removed then this reference will refer to the main screen.
> 
> The problem in the current implementation arise when the system has two video cards:
>   1 The user get some GraphicsDevice
>   2 The user sets the full-screen window for this device
>   3 The user change screen resolution for this device
>   4 The resolution of the screen is not changed ->> BUG.
> 
> The problem is that somewhere after step 1 or 2 and before step 3 the macOS decided
> to switch to the discrete video card, but it does not report the old device(integrated VC)
> as removed, because actually no screens were removed.
> 
> Since it was not reported as removed we did not invalidate it and did not map it to the
> new device ->> request to change the screen resolution at step 3 send to some non existed
> deviceID.
> 
> As a fix I suggest to change this current logic:
>   - Invalidate devices reported by macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
> 
> To this logic:
>   - Ignore devices reported by the macOS as removed
>   - Initialize the main screen
>   - Initialize all NEW screens
>   - Check that the main device is in the list of all NEW devices
>   - Invalidate all OLD devices which are not in the list of NEW devices
> 
> The old review request:
> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/011011.html

This pull request has now been integrated.

Changeset: e5870cf0
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/e5870cf0
Stats:     111 lines in 3 files changed: 54 ins; 26 del; 31 mod

8252133: The java/awt/GraphicsDevice/DisplayModes/CycleDMImage.java fails if metal pipeline is active

Reviewed-by: prr

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

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

From kizune at openjdk.java.net  Wed Oct 21 02:45:13 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 21 Oct 2020 02:45:13 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254863: Delete code leftover from old
 fixes
In-Reply-To: <0kYrD4NOgECoyPSAuT-mvmm3aYQi2EWpBMT75CCwXcE=.2d220413-e99e-4632-9b7b-33661692f386@github.com>
References: <0kYrD4NOgECoyPSAuT-mvmm3aYQi2EWpBMT75CCwXcE=.2d220413-e99e-4632-9b7b-33661692f386@github.com>
Message-ID: 

On Fri, 16 Oct 2020 02:31:09 GMT, Sergey Bylokhov  wrote:

> The fix for JDK-4893408 adds a special code to handle the "PYCC.pf" color profile for the "kernel java":
> https://bugs.openjdk.java.net/browse/JDK-4893408?focusedCommentId=12284308&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12284308
> The "kernel java" support was removed in jdk7 in JDK-7016724 but the special code in the ICC_Profile.java still exists.
> 
> After the fix for JDK-8175984 a few methods became unused:
>  - CMSManager#freeProfile()
>  - ProfileDeferralMgr#unregisterDeferral()

Marked as reviewed by kizune (Reviewer).

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

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

From serb at openjdk.java.net  Wed Oct 21 04:59:11 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 21 Oct 2020 04:59:11 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8255043: Incorrectly styled copyright
 text
In-Reply-To: 
References: 
Message-ID: 

On Tue, 20 Oct 2020 08:17:27 GMT, Sergey Bylokhov  wrote:

> In some files, the copyright text is styled as a JavaDoc comment.
> Most of the affected files are tests, only one product file is affected:
> src/java.sql/share/classes/javax/sql/package-info.java
> 
> The chenge is trivial:
>  - /**
>  + /*
>     * Copyright (c)

This pull request has now been integrated.

Changeset: 2e510e04
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/2e510e04
Stats:     49 lines in 49 files changed: 0 ins; 0 del; 49 mod

8255043: Incorrectly styled copyright text

Reviewed-by: dholmes, trebari, jdv

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

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

From serb at openjdk.java.net  Thu Oct 22 08:44:11 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 22 Oct 2020 08:44:11 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction
In-Reply-To: 
References: 
Message-ID: 

On Wed, 21 Oct 2020 11:50:37 GMT, Prasanta Sadhukhan  wrote:

> Please review a manual printing test failure where the instructions is not matching the printing result 
> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
> as the labels in the test instruction is fully left aligned starting from 0.
> Fixed by adding some spaces before labels and 
> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.

Probably we should not use some hardcoded values but use some paper related insets? Don't we need to update the public int print(Graphics graphics) instead and scale the frame to the paper, or just translate the graphics passed to print() before passing it to this.paint()?

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

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

From prr at openjdk.java.net  Sat Oct 24 23:01:35 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 24 Oct 2020 23:01:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction
In-Reply-To: 
References: 
Message-ID: <7NrkhfViQIe0rvSp6T5c0SqJB8QO_Xc7qSfRlHRTK5Q=.4e4b4c47-48ad-4b25-927c-ae1930d2b7d2@github.com>

On Wed, 21 Oct 2020 11:50:37 GMT, Prasanta Sadhukhan  wrote:

> Please review a manual printing test failure where the instructions is not matching the printing result 
> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
> as the labels in the test instruction is fully left aligned starting from 0.
> Fixed by adding some spaces before labels and 
> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.

test/jdk/java/awt/print/bug8023392/bug8023392.java line 77:

> 75:             setLayout(new BorderLayout());
> 76:             label1 = new JLabel("  2a) a b c d e" +
> 77:                     "                         ");

See my general comment - this needs to be changed.

test/jdk/java/awt/print/bug8023392/bug8023392.java line 49:

> 47: public class bug8023392 extends Applet {
> 48:     static final String[] instructions = {
> 49:         "Please select variable radiobutton in applet.",

why?  And the text reads oddly,  I think you mean
"Please select the Radio Button for applet size labeled "sariable"  in the test harness window"
but still, why ??

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

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

From prr at openjdk.java.net  Sat Oct 24 23:12:38 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sat, 24 Oct 2020 23:12:38 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254370: Update the classes in the
 java.awt.color package
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Oct 2020 18:23:48 GMT, Sergey Bylokhov  wrote:

> - The spec  for ICC_ProfileRGB.getGamma(int) and ICC_ProfileRGB.getTRC(int) is updated
>  - Two additional tests are added to cover some basic specified functionality
>  - Some code in these classes was simplified/cleaned
>  - Some common code is extracted to the separate methods.

src/java.desktop/share/classes/java/awt/color/ICC_ProfileGray.java line 146:

hmm this old code looked like it might be trying to avoid its own override but no such override exists ...

src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java line 209:

> 207:      *         {@code REDCOMPONENT}, {@code GREENCOMPONENT}, or
> 208:      *         {@code BLUECOMPONENT}
> 209:      * @throws ProfileDataException if the profile does not specify the

You said no CSR is needed but you document a previously undocumented exception, so I think a CSR is warranted

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

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

From serb at openjdk.java.net  Sun Oct 25 01:08:35 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 25 Oct 2020 01:08:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254370: Update the classes in the
 java.awt.color package
In-Reply-To: 
References: 

Message-ID: <0l_g-vdqgU_vIJHcX9y5Cwid5sVkzJ8-69f1ttohNF4=.803e2f20-cbab-4fb8-82fa-6061cdcd254f@github.com>

On Sat, 24 Oct 2020 23:09:44 GMT, Phil Race  wrote:

>> - The spec  for ICC_ProfileRGB.getGamma(int) and ICC_ProfileRGB.getTRC(int) is updated
>>  - Two additional tests are added to cover some basic specified functionality
>>  - Some code in these classes was simplified/cleaned
>>  - Some common code is extracted to the separate methods.
>
> src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java line 209:
> 
>> 207:      *         {@code REDCOMPONENT}, {@code GREENCOMPONENT}, or
>> 208:      *         {@code BLUECOMPONENT}
>> 209:      * @throws ProfileDataException if the profile does not specify the
> 
> You said no CSR is needed but you document a previously undocumented exception, so I think a CSR is warranted

CSR is needed and linked from the JBS, and after a few attempts, it is referenced from this pull request a few comments above.

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

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

From prr at openjdk.java.net  Sun Oct 25 01:23:35 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 25 Oct 2020 01:23:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254370: Update the classes in the
 java.awt.color package
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Oct 2020 18:23:48 GMT, Sergey Bylokhov  wrote:

> - The spec  for ICC_ProfileRGB.getGamma(int) and ICC_ProfileRGB.getTRC(int) is updated
>  - Two additional tests are added to cover some basic specified functionality
>  - Some code in these classes was simplified/cleaned
>  - Some common code is extracted to the separate methods.

Marked as reviewed by prr (Reviewer).

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

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

From prr at openjdk.java.net  Sun Oct 25 01:23:36 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 25 Oct 2020 01:23:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254370: Update the classes in the
 java.awt.color package
In-Reply-To: <0l_g-vdqgU_vIJHcX9y5Cwid5sVkzJ8-69f1ttohNF4=.803e2f20-cbab-4fb8-82fa-6061cdcd254f@github.com>
References: 

 <0l_g-vdqgU_vIJHcX9y5Cwid5sVkzJ8-69f1ttohNF4=.803e2f20-cbab-4fb8-82fa-6061cdcd254f@github.com>
Message-ID: 

On Sun, 25 Oct 2020 01:06:18 GMT, Sergey Bylokhov  wrote:

>> src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java line 209:
>> 
>>> 207:      *         {@code REDCOMPONENT}, {@code GREENCOMPONENT}, or
>>> 208:      *         {@code BLUECOMPONENT}
>>> 209:      * @throws ProfileDataException if the profile does not specify the
>> 
>> You said no CSR is needed but you document a previously undocumented exception, so I think a CSR is warranted
>
> CSR is needed and linked from the JBS, and after a few attempts, it is referenced from this pull request a few comments above.

Ok. There's a very weird sequence above of it being added, and you removing it and whatever so it is confusing.
I'll find the CSR and review / ok it.

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

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

From serb at openjdk.java.net  Sun Oct 25 02:55:37 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 25 Oct 2020 02:55:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs
In-Reply-To: 
References: 
Message-ID: 

On Sun, 11 Oct 2020 19:58:20 GMT, Daniel Kamil Kozar  wrote:

> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
> 
> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
> 
> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
> 
> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.

Description of possible ways to interact with a clipboard:
https://docs.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard

> There are three ways of monitoring changes to the clipboard. The oldest method is to create a clipboard viewer window. Windows 2000 added the ability to query the clipboard sequence number, and Windows Vista added support for clipboard format listeners. Clipboard viewer windows are supported for backward compatibility with earlier versions of Windows. New programs should use clipboard format listeners or the clipboard sequence number.

The current fix proposes to change the old "clipboard viewer window" approach:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboardviewer
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-changeclipboardchain
To the new approach:
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-addclipboardformatlistener

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

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

From serb at openjdk.java.net  Sun Oct 25 02:55:37 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 25 Oct 2020 02:55:37 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs
In-Reply-To: 
References: 

Message-ID: 

On Sun, 25 Oct 2020 02:51:41 GMT, Sergey Bylokhov  wrote:

>> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
>> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
>> 
>> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
>> 
>> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
>> 
>> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.
>
> Description of possible ways to interact with a clipboard:
> https://docs.microsoft.com/en-us/windows/win32/dataxchg/using-the-clipboard
> 
>> There are three ways of monitoring changes to the clipboard. The oldest method is to create a clipboard viewer window. Windows 2000 added the ability to query the clipboard sequence number, and Windows Vista added support for clipboard format listeners. Clipboard viewer windows are supported for backward compatibility with earlier versions of Windows. New programs should use clipboard format listeners or the clipboard sequence number.
> 
> The current fix proposes to change the old "clipboard viewer window" approach:
> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setclipboardviewer
> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-changeclipboardchain
> To the new approach:
> https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-addclipboardformatlistener

I have run the tests and waiting for the results, will sponsor it if the results will be good.

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

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

From serb at openjdk.java.net  Sun Oct 25 02:58:35 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 25 Oct 2020 02:58:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs
In-Reply-To: 
References: 
Message-ID: 

On Sun, 11 Oct 2020 19:58:20 GMT, Daniel Kamil Kozar  wrote:

> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
> 
> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
> 
> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
> 
> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.

Please update the second date in the header of the changed files to 2020.

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

Changes requested by serb (Reviewer).

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

From psadhukhan at openjdk.java.net  Sun Oct 25 07:37:39 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Sun, 25 Oct 2020 07:37:39 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction
In-Reply-To: <7NrkhfViQIe0rvSp6T5c0SqJB8QO_Xc7qSfRlHRTK5Q=.4e4b4c47-48ad-4b25-927c-ae1930d2b7d2@github.com>
References: 
 <7NrkhfViQIe0rvSp6T5c0SqJB8QO_Xc7qSfRlHRTK5Q=.4e4b4c47-48ad-4b25-927c-ae1930d2b7d2@github.com>
Message-ID: 

On Sat, 24 Oct 2020 22:59:20 GMT, Phil Race  wrote:

>> Please review a manual printing test failure where the instructions is not matching the printing result 
>> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
>> as the labels in the test instruction is fully left aligned starting from 0.
>> Fixed by adding some spaces before labels and 
>> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
>> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.
>
> test/jdk/java/awt/print/bug8023392/bug8023392.java line 49:
> 
>> 47: public class bug8023392 extends Applet {
>> 48:     static final String[] instructions = {
>> 49:         "Please select variable radiobutton in applet.",
> 
> why?  And the text reads oddly,  I think you mean
> "Please select the Radio Button for applet size labeled "sariable"  in the test harness window"
> but still, why ??

Even now, in "fixed" mode the "Print" button is not visible and we need to select "Variable" to see the button. I just made it more official by changing the instruction.
BTW, I dont see the general comment about the label...I will work on the getting the inset than adding spaces in label.

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

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

From github.com+127875+xavery at openjdk.java.net  Sun Oct 25 18:41:48 2020
From: github.com+127875+xavery at openjdk.java.net (Daniel Kamil Kozar)
Date: Sun, 25 Oct 2020 18:41:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs [v2]
In-Reply-To: 
References: 
Message-ID: 

> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
> 
> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
> 
> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
> 
> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.

Daniel Kamil Kozar has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright headers to 2020

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/594/files
  - new: https://git.openjdk.java.net/jdk/pull/594/files/c39c39a5..be1b6cbf

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

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/594.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/594/head:pull/594

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

From github.com+127875+xavery at openjdk.java.net  Sun Oct 25 18:41:48 2020
From: github.com+127875+xavery at openjdk.java.net (Daniel Kamil Kozar)
Date: Sun, 25 Oct 2020 18:41:48 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs [v2]
In-Reply-To: 
References: 

Message-ID: <3eM1qNXy4eVJNOrP7Qos4QTPgQiDnMw8WWv-RnF30sc=.a3efeb42-b811-4463-a05a-509a2660dbde@github.com>

On Sun, 25 Oct 2020 02:55:38 GMT, Sergey Bylokhov  wrote:

> Please update the second date in the header of the changed files to 2020.

Done.

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

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

From serb at openjdk.java.net  Sun Oct 25 22:18:35 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 25 Oct 2020 22:18:35 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8254825: Monitoring available clipboard
 formats should be done via new Windows APIs [v2]
In-Reply-To: 
References: 

Message-ID: 

On Sun, 25 Oct 2020 18:41:48 GMT, Daniel Kamil Kozar  wrote:

>> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
>> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
>> 
>> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
>> 
>> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
>> 
>> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.
>
> Daniel Kamil Kozar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers to 2020

Looks fine

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

Marked as reviewed by serb (Reviewer).

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

From github.com+127875+xavery at openjdk.java.net  Mon Oct 26 19:16:22 2020
From: github.com+127875+xavery at openjdk.java.net (Daniel Kamil Kozar)
Date: Mon, 26 Oct 2020 19:16:22 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8254825: Monitoring available
 clipboard formats should be done via new Windows APIs
In-Reply-To: 
References: 
Message-ID: <-rPQeOLOC_eQuSTsRQys8W44X14lb13AOusyb0qhesY=.0c6e23b9-c03b-4229-9fb2-ffbd60564e1d@github.com>

On Sun, 11 Oct 2020 19:58:20 GMT, Daniel Kamil Kozar  wrote:

> This change replaces the usage of SetClipboardViewer with Add/RemoveClipboardFormatListener, introduced in Windows Vista. This makes OpenJDK immune to external applications failing to process clipboard messages properly.
> I have put this proposal forward in the [mailing list](https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015990.html), which was tentatively accepted by Mr. Sergey Bylokhov.
> 
> The deficiencies of the old APIs are well known and might result in some subscribed applications not receiving notifications from the operating system, as they rely on all the applications in the current clipboard chain processing clipboard messages properly. Porting the code to use the new APIs not only makes OpenJDK immune to these issues, but also results in slightly less code needed to support clipboard-related functionality.
> 
> As this is a change that's very platform-specific, I don't think providing a unit test is practical, as it would also require providing a native application that runs alongside the test and deliberately breaks the keyboard chain, resulting in OpenJDK not being able to receive clipboard format change notifications. This is a bug/limitation of the old Windows API, not OpenJDK itself. Anyhow, the already existing ClipboardInterVMTest passes, which shows that already existing functionality is not impacted by this change.
> 
> I have prepared a proof-of-concept test which illustrates the deficiencies of the old API, however it is not integrated with the test suite, as it requires compiling a native WinAPI application. I will gladly share the source if needed.

This pull request has now been integrated.

Changeset: b4984336
Author:    Daniel Kamil Kozar 
Committer: Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/b4984336
Stats:     39 lines in 4 files changed: 0 ins; 28 del; 11 mod

8254825: Monitoring available clipboard formats should be done via new Windows APIs

Reviewed-by: serb

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

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

From serb at openjdk.java.net  Mon Oct 26 20:04:33 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Oct 2020 20:04:33 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6847157: java.lang.NullPointerException: HDC
 for component at sun.java2d.loops.Blit.Blit
Message-ID: 

This is the fix for one suspicious exception which rarely but time to time occurred on the test systems. As described in a few bug reports the use-cases could be quite different, but I was able to reproduce it in one of them.

Steps to reproduce:
 1. We draw to the frame for the first time or we draw to the frame on the thread where we never draw before
 2. As part of step 1. we start initialization of the surface data bounded to this frame for that thread, in the native method
 3. jtreg decided to kill the test because the main method ends
 4. As part of step 2. we request HDC for the frame via sendMessage which do nothing since AWT is stopping/dies -> HDC=NULL
 5. As part of step 1. we try to draw to the surface -> HDC is NULL -> NPE is thrown

The solution is to mark the surface at step 4. as invalid:
 - If the AWT will die this surface will never be used and no exception occurs
 - If the application will continue to work and this surface will be accessed then we will throw InvalidPipeException in attempts to recreate the surface and all related data.

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

Commit messages:
 - Update RepaintOnAWTShutdown.java
 - Initial fix

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

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

From serb at openjdk.java.net  Mon Oct 26 20:04:34 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 26 Oct 2020 20:04:34 GMT
Subject: [OpenJDK 2D-Dev] RFR: 6847157: java.lang.NullPointerException:
 HDC for component at sun.java2d.loops.Blit.Blit
In-Reply-To: 
References: 
Message-ID: 

On Mon, 26 Oct 2020 19:45:49 GMT, Sergey Bylokhov  wrote:

> This is the fix for one suspicious exception which rarely but time to time occurred on the test systems. As described in a few bug reports the use-cases could be quite different, but I was able to reproduce it in one of them.
> 
> Steps to reproduce:
>  1. We draw to the frame for the first time or we draw to the frame on the thread where we never draw before
>  2. As part of step 1. we start initialization of the surface data bounded to this frame for that thread, in the native method
>  3. jtreg decided to kill the test because the main method ends
>  4. As part of step 2. we request HDC for the frame via sendMessage which do nothing since AWT is stopping/dies -> HDC=NULL
>  5. As part of step 1. we try to draw to the surface -> HDC is NULL -> NPE is thrown
> 
> The solution is to mark the surface at step 4. as invalid:
>  - If the AWT will die this surface will never be used and no exception occurs
>  - If the application will continue to work and this surface will be accessed then we will throw InvalidPipeException in attempts to recreate the surface and all related data.

test/jdk/java/awt/Paint/RepaintOnAWTShutdown.java line 51:

> 49:  * @run main/othervm -Dsun.java2d.uiScale=2.25 RepaintOnAWTShutdown
> 50:  * @run main/othervm -Dsun.java2d.uiScale=5    RepaintOnAWTShutdown
> 51:  * @run main/othervm -Dsun.java2d.uiScale=10   RepaintOnAWTShutdown

The bug depends on the CPU/GPU performance so I tried to reproduce it by tweaking the number of pixels to draw.

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

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

From serb at openjdk.java.net  Tue Oct 27 00:02:22 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 27 Oct 2020 00:02:22 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8254370: Update the classes in the
 java.awt.color package
In-Reply-To: 
References: 
Message-ID: 

On Mon, 12 Oct 2020 18:23:48 GMT, Sergey Bylokhov  wrote:

> - The spec  for ICC_ProfileRGB.getGamma(int) and ICC_ProfileRGB.getTRC(int) is updated
>  - Two additional tests are added to cover some basic specified functionality
>  - Some code in these classes was simplified/cleaned
>  - Some common code is extracted to the separate methods.

This pull request has now been integrated.

Changeset: abdbbe3a
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.java.net/jdk/commit/abdbbe3a
Stats:     389 lines in 6 files changed: 284 ins; 77 del; 28 mod

8254370: Update the classes in the java.awt.color package

Reviewed-by: prr

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

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

From psadhukhan at openjdk.java.net  Tue Oct 27 07:24:36 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 27 Oct 2020 07:24:36 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction [v2]
In-Reply-To: 
References: 
Message-ID: 

> Please review a manual printing test failure where the instructions is not matching the printing result 
> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
> as the labels in the test instruction is fully left aligned starting from 0.
> Fixed by adding some spaces before labels and 
> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.

Prasanta Sadhukhan 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 two additional commits since the last revision:

 - Merge branch 'master' into JDK-8231231
 - 8231231: The printing result is different from the case instruction

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/780/files
  - new: https://git.openjdk.java.net/jdk/pull/780/files/cc121c06..89d21206

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

  Stats: 65759 lines in 901 files changed: 49411 ins; 12357 del; 3991 mod
  Patch: https://git.openjdk.java.net/jdk/pull/780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/780/head:pull/780

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

From psadhukhan at openjdk.java.net  Tue Oct 27 07:50:30 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 27 Oct 2020 07:50:30 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction [v3]
In-Reply-To: 
References: 
Message-ID: 

> Please review a manual printing test failure where the instructions is not matching the printing result 
> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
> as the labels in the test instruction is fully left aligned starting from 0.
> Fixed by adding some spaces before labels and 
> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Translate the graphics context origin to x,y coordinate of paper's imageable area

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/780/files
  - new: https://git.openjdk.java.net/jdk/pull/780/files/89d21206..96c1c7a8

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

  Stats: 17 lines in 2 files changed: 2 ins; 1 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/780.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/780/head:pull/780

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

From prr at openjdk.java.net  Tue Oct 27 11:01:22 2020
From: prr at openjdk.java.net (Phil Race)
Date: Tue, 27 Oct 2020 11:01:22 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8231231: The printing result is different
 from the case instruction [v3]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 27 Oct 2020 07:50:30 GMT, Prasanta Sadhukhan  wrote:

>> Please review a manual printing test failure where the instructions is not matching the printing result 
>> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
>> as the labels in the test instruction is fully left aligned starting from 0.
>> Fixed by adding some spaces before labels and 
>> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
>> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Translate the graphics context origin to x,y coordinate of paper's imageable area

Marked as reviewed by prr (Reviewer).

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

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

From psadhukhan at openjdk.java.net  Tue Oct 27 11:23:18 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 27 Oct 2020 11:23:18 GMT
Subject: [OpenJDK 2D-Dev] Integrated: 8231231: The printing result is
 different from the case instruction
In-Reply-To: 
References: 
Message-ID: <_hu7tSfsCkVfdQbXVdTTYp9DT64ueBU6DkbPF7YzNWg=.b46618a3-5b3e-471c-b600-fed844be6f80@github.com>

On Wed, 21 Oct 2020 11:50:37 GMT, Prasanta Sadhukhan  wrote:

> Please review a manual printing test failure where the instructions is not matching the printing result 
> as the labels which are present in the test instruction frame is cut off in printed result due to margin not being accounted for, 
> as the labels in the test instruction is fully left aligned starting from 0.
> Fixed by adding some spaces before labels and 
> for other labels drawn through drawChars, modified to draw the labels from coordinate 20 instead of 0 to allow labels being printed in the paper and not get cutoff by margin.
> Also, the Print instruction is brought to top and 1st label is brought to bottom (SOUTH position in BorderLayout) as 1st label is in JScrollPane so to account for top margin cutoff, brought it lower so that those labels does not get cut off.

This pull request has now been integrated.

Changeset: 76796504
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.java.net/jdk/commit/76796504
Stats:     5 lines in 2 files changed: 3 ins; 1 del; 1 mod

8231231: The printing result is different from the case instruction

Reviewed-by: prr

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

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

From serb at openjdk.java.net  Tue Oct 27 23:35:26 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 27 Oct 2020 23:35:26 GMT
Subject: [OpenJDK 2D-Dev] RFR: 4619330: some of java.awt.color.ColorSpace
 fields should specified that build-in
Message-ID: 

The wording for ColorSpace.CS_XXX is unified.

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

Commit messages:
 - Update ColorSpace.java

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

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

From aivanov at openjdk.java.net  Wed Oct 28 20:47:50 2020
From: aivanov at openjdk.java.net (Alexey Ivanov)
Date: Wed, 28 Oct 2020 20:47:50 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v2]
In-Reply-To: 
References: 

Message-ID: 

On Sun, 4 Oct 2020 06:22:45 GMT, Sergey Bylokhov  wrote:

>> Hello.
>> Please review the fix for jdk.
>> 
>> Old review request:
>> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
>> 
>> 
>> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
>> Windows 7, because it does not support different DPI for different monitors)
>> 
>> ========================================================
>> Short description:
>>      In the multi-screen configurations when each screen have different DPI
>>      we calculate the bounds of each monitor by these formulas:
>> 
>>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
>> 
>>   This formula makes the next configuration completely broken:
>>     - The main screen on the left and 100% DPI
>>     - The second screen on the right and 200% DPI
>>   When we translate the bounds of the config from the device space to the user's space,
>>      the bounds of both screen overlap in the user's space, because we use bounds of
>>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
>> 
>>   Since the screens are overlapped we cannot be sure how to translate the user's space
>>    coordinates to device space in the overlapped zone.
>>   As a result => we use the wrong screen
>>                    => got wrong coordinates in the device space
>>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
>> 
>>    The proposed solution for this bug is to change the formulas to these:
>> 
>>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
>> 
>>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
>> 
>>    Before the fix:
>> 
>>          userX = deviceX * scaleX;
>>          deviceX = userX / scaleX;
>> 
>>    After the fix(only the part appeared on this screen should be scaled)
>> 
>>          userX = screenX + (deviceX - screenX) * scaleX
>>          deviceX = screenX + (userX - screenX) / scaleX
>> 
>>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>>    If we will need to calculate the "size" such as W and H then the old formula should be used.
>> 
>>    The main changes for the problem above are:
>>    - Skip transformation of X and Y of the screen bounds:
>>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>>    - A number of utility methods in java and native:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>>    
>> 
>> ========================================================
>> Long description:
>>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>>      have different DPI, even if the bounds are *NOT* overlapped.
>> 
>>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>>      expected device position based on the current GraphicsConfiguration of the peer, and then
>>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>>      the config might be changed and the tweak in native will use a different screen).
>> 
>>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>>      on the toolkit thread:
>>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>>      
>> 
>>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>>   
>>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>>      See the end of void AwtWindow::Reshape():
>>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>> 
>>   -  Currently the HW componets such as Canvas scales everything based on such code:
>> 
>>           770 int AwtComponent::ScaleUpX(int x) {
>>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>>           4772     Devices::InstanceAccess devices;
>>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>>           4774     return device == NULL ? x : device->ScaleUpX(x);
>>           4775 }
>> 
>>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
>> 
>>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
>> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
>> 
>>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
>> 
>>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
>> 
>>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
>> 
>>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
>> 
>> ========================================================
>> Some other bugs which are not fixed.
>> 
>>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>>       because later we reshape the component to the correct bounds. Will fix it later.
>> 
>>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>>       coordinates in the user's space to the field which use device space:
>>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
>> 
>> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>>      
>> 
>> ========================================================
>> The tests
>>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>>       in my initial implementation
>>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
>> 
>> ========================================================
>> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
>> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
>> 
>> The mach5 is also green.
>> 
>> PS: hope I did not forget some important information, will send it later if any.
>
> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8211999
>  - Update FullscreenWindowProps.java
>  - Merge branch 'master' into JDK-8211999
>  - Fix fullscreen in HiDPI mode
>  - self review
>  - Initial fix version

src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 445:

> 443:      * @return the point which uses device space(pixels)
> 444:      */
> 445:     public static Point toDeviceSpace(int x, int y) {

Does this function converts _absolute_ coordinates?
I see it uses a different formula to convert: the coordinates are scaled as opposed to `-Abs` set of functions.

src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java line 539:

> 537:         winGraphicsConfig = (Win32GraphicsConfig)gc;
> 538:         if (gc != null && !old.equals(gc.getDefaultTransform())) {
> 539:             syncBounds(); // the bound of the peer depends on the DPI

Suggestion:

            syncBounds(); // the bounds of the peer depend on the DPI

src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 311:

> 309: 
> 310:     final void syncBounds(){
> 311:         // The Windows will take care of the top-level window/frame/dialog,

Suggestion:

    final void syncBounds() {
        // Windows will take care of the top-level window/frame/dialog,

Does it override another implementation of `syncBounds()`? Or does it implement a method in an interface?
Shall it have `@Override` annotation?

src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp line 692:

> 690: }
> 691: 
> 692: void AwtWin32GraphicsDevice::InitDesktopScales() {

Suggestion:

void AwtWin32GraphicsDevice::InitDesktopScales()
{
Shall the opening brace remain on the next line as it was for consistency with other functions?

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1211:

> 1209:     int screen = AwtWin32GraphicsDevice::GetScreenFromHMONITOR(monitor);
> 1210:     AwtWin32GraphicsDevice *device = devices->GetDevice(screen);
> 1211:     // Try set the correct size and jump to the correct location, even if it is

Suggestion:

    // Try to set the correct size and jump to the correct location, even if it is

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2197:

> 2195: // The shared code is not ready to the top-level window which crosses a few
> 2196: // monitors with different DPI. Popup windows will start to use wrong screen,
> 2197: // will be placed in the wrong place and will be use wrong size, see 8249164

Suggestion:

// will be placed in the wrong place and will use the wrong size, see 8249164

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2217:

> 2215:                     y = y < bounds.top ? bounds.top : y;
> 2216:                     x = (x + w > bounds.right) ? bounds.right - w : x;
> 2217:                     y = (y + h > bounds.bottom) ? bounds.bottom - h : y;

Can't this adjustment cause `x`, `y` to become less than `bounds.left` and `bounds.top` correspondingly?
Shall it adjust the width and height?

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3987:

> 3985: }
> 3986: 
> 3987: } /* extern "C" */

Probably, it's better to preserve the line end at the end of the file.

test/jdk/java/awt/Component/SetComponentsBounds/SetComponentsBounds.java line 102:

> 100:                 }
> 101:                 if (bounds.height > HEIGHT) {
> 102:                     // different check for HEIGHT, it depends from the font

Suggestion:

                    // different check for HEIGHT, it depends on the font

test/jdk/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest.java line 90:

> 88:             for (int i = 0; i < aList.getItemCount(); i++) {
> 89:                 //select all items in the List
> 90:                 mousePress(p.x + listSize.height / 2, p.y + stepY / 2 + stepY * i);

x be based on width?
                mousePress(p.x + listSize.width / 2, p.y + stepY / 2 + stepY * i);

test/jdk/java/awt/Window/WindowSizeDifferentScreens/WindowSizeDifferentScreens.java line 110:

> 108:             case "dialog" -> new Dialog((Dialog) null);
> 109:             case "frame" -> new Frame();
> 110:             default -> throw new IllegalStateException("Unexpected: " + top);

`IllegalArgumentException` more appropriate?
            default -> throw new IllegalArgumentException("Unexpected: " + top);

test/jdk/javax/swing/JTextArea/8149849/DNDTextToScaledArea.java line 81:

> 79:         robot.mousePress(InputEvent.BUTTON1_MASK);
> 80:         robot.mouseRelease(InputEvent.BUTTON1_MASK);
> 81:         robot.waitForIdle();

Why is clicking the `dstTextArea` required?

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

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

From serb at openjdk.java.net  Wed Oct 28 23:05:58 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 23:05:58 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v3]
In-Reply-To: 
References: 
Message-ID: 

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review

  Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/375/files
  - new: https://git.openjdk.java.net/jdk/pull/375/files/5f0bb7de..f6016592

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

  Stats: 8 lines in 4 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/375/head:pull/375

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

From serb at openjdk.java.net  Wed Oct 28 23:46:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 23:46:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v4]
In-Reply-To: 
References: 
Message-ID: 

> Hello.
> Please review the fix for jdk.
> 
> Old review request:
> https://mail.openjdk.java.net/pipermail/awt-dev/2020-July/015991.html
> 
> 
> (Note: the fix use API available since Windows 8.1: WM_DPICHANGED, but it should be fine for
> Windows 7, because it does not support different DPI for different monitors)
> 
> ========================================================
> Short description:
>      In the multi-screen configurations when each screen have different DPI
>      we calculate the bounds of each monitor by these formulas:
> 
>          userSpaceBounds = deviceX / scaleX, deviceY / scaleY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX * scaleX, userY * scaleY, userW * scaleX, userH * scaleY
> 
>   This formula makes the next configuration completely broken:
>     - The main screen on the left and 100% DPI
>     - The second screen on the right and 200% DPI
>   When we translate the bounds of the config from the device space to the user's space,
>      the bounds of both screen overlap in the user's space, because we use bounds of
>      the main screen as-is, and the X/Y of the second screen are divided by the scaleX/Y.
> 
>   Since the screens are overlapped we cannot be sure how to translate the user's space
>    coordinates to device space in the overlapped zone.
>   As a result => we use the wrong screen
>                    => got wrong coordinates in the device space
>                      => show top-level windows/popups/tooltips/menus/etc on the wrong screen
> 
>    The proposed solution for this bug is to change the formulas to these:
> 
>          userSpaceBounds = deviceX, deviceY, deviceW / scaleX, deviceH / scaleY
>          devSpaceBounds  = userX, userY, userW * scaleX, userH * scaleY
> 
>    In other words, we should not transform the X and Y coordinates of the screen(the top/left corner). This will
>    complicate the way of how we transform coordinates on the screen: user's <--> device spaces:
> 
>    Before the fix:
> 
>          userX = deviceX * scaleX;
>          deviceX = userX / scaleX;
> 
>    After the fix(only the part appeared on this screen should be scaled)
> 
>          userX = screenX + (deviceX - screenX) * scaleX
>          deviceX = screenX + (userX - screenX) / scaleX
> 
>    Note that these new formulas are applicable only for the coordinates on the screen such as X and Y.
>    If we will need to calculate the "size" such as W and H then the old formula should be used.
> 
>    The main changes for the problem above are:
>    - Skip transformation of X and Y of the screen bounds:
>        http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsConfig.cpp.sdiff.html
>    - A number of utility methods in java and native:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Win32GraphicsDevice.cpp.sdiff.html
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java.sdiff.html
>    
> 
> ========================================================
> Long description:
>      Unfortunately, the changes above are not enough to fix the problem when different monitors
>      have different DPI, even if the bounds are *NOT* overlapped.
> 
>    - Currently, when we try to set the bounds of the window, we manually convert it in "java" to the
>      expected device position based on the current GraphicsConfiguration of the peer, and then
>      additionally, tweak it in native using the device scale stored in native code. Unfortunately
>      this two scale might not be in sync:(after we use the GraphicsConfiguration scale in peer,
>      the config might be changed and the tweak in native will use a different screen).
> 
>      As a fix I have moved all transformation from the peer to the native code, it will be executed
>      on the toolkit thread:
>      See the change in WWindowPeer.setBounds() and awt_Window.cpp AwtWindow::Reshape
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java.sdiff.html
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
>      I think at some point we should delete all transformation in java, and apply it in the native code only.
>      
> 
>    - We had a special code that tracked the dragging of the window by the user from one screen to another,
>      and change the size of the window only when the user stops the drag operation. I've proposed to use standard Windows
>      machinery for that via WM_DPICHANGED: https://docs.microsoft.com/en-us/windows/win32/hidpi/wm-dpichanged
>      As a result, Windows will provide the "best" windows bounds on the new screen. Note that the code has a
>      workaround for https://bugs.openjdk.java.net/browse/JDK-8249164
>   
>    - I've also fix a variation of the bug previously fixed on macOS https://hg.openjdk.java.net/jdk/jdk/rev/b5cdba232fca
>      If we try to change the position of the window, and Windows ignores this request then we need to call all "callbacks" manually, otherwise, the shared code will use the bounds ignored by the Windows.
>      See the end of void AwtWindow::Reshape():
>      http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Window.cpp.sdiff.html
> 
>   -  Currently the HW componets such as Canvas scales everything based on such code:
> 
>           770 int AwtComponent::ScaleUpX(int x) {
>           4771     int screen = AwtWin32GraphicsDevice::DeviceIndexForWindow(GetHWnd());
>           4772     Devices::InstanceAccess devices;
>           4773     AwtWin32GraphicsDevice* device = devices->GetDevice(screen);
>           4774     return device == NULL ? x : device->ScaleUpX(x);
>           4775 }
> 
>   But it does not work well if the smaller part of the top-level window is located on one screen1(DPI=100) but
>      the biggest part is located on the screen2(DPI=200). If the Canvas is located on the "smaller" part of the
>      window, then the canvas will use DPI=100 for scale, but the whole window will use DPI=200
> 
>    As a fix, all HW components will try to use the scale factor of the top-level window, see AwtComponent::GetScreenImOn:
> http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp.sdiff.html
> 
>    - Our current implementation does not take care of the case when the HW component bounds are updated when the top-level
>      the window is moved to another screen. For example, if the window does not use LayoutManager and the user sets some specific bounds for the Canvas. It is expected that the size of the Canvas will be updated when the window will be moved to another screen, but only HW top-level window and Swing components will update its size.
> 
>      As a fix I suggest to resync the bounds of the HW components if the GraphicsCOnfiguration is changed, see WComponentPeer.syncBounds():
>          http://cr.openjdk.java.net/~serb/8211999/webrev.04/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java.sdiff.html
> 
>    - Note that the current fix is for Windows only, but the bug exists on Linux as well, so I have to create a kind of "ifdef" in the
>      Robot class, on windows we will use the new logic, on other platforms the old logic will be used.
> 
>    - The win32GraphicsDevice incorrectly sets the size of the full-screen window. It uses the display mode width/height(which are stored in pixels), but the bounds of the graphics config(which are stored in user's space) should be used.
> 
> ========================================================
> Some other bugs which are not fixed.
> 
>     - We have a lot of places where we mix(unintentionally) the coordinate in user's space and device space.
>       For example when we create the component we read x/y/width/height by the JNI(of course in a user's space)
>       but pass this coordinates as-is to the ::CreateWindowEx() which is incorrect. It works currently
>       because later we reshape the component to the correct bounds. Will fix it later.
> 
>     - When the frame is iconized and we try to save a new bounds for the future use, we store the
>       coordinates in the user's space to the field which use device space:
>       https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp#L664
> 
> Probably there are some other bugs and possibility to cleanups, but I would like to do that in separate issues.
>      
> 
> ========================================================
> The tests
>     - I have updated a couple of the tests to check multiple screens if possible, it helps to found some bugs
>       in my initial implementation
>     - Four new tests were added: SetComponentsBounds, SlowMotion, WindowSizeDifferentScreens, FullscreenWindowProps
>     - One test is moved from the closed repo(I made a small cleanup of it): ListMultipleSelectTest
> 
> ========================================================
> I have run jck, regression tests in different configurations, when the main screen is on the left, up, down,
> right, and have different DPI such as 100, 125, 150, and 200. No new issues were found so far.
> 
> The mach5 is also green.
> 
> PS: hope I did not forget some important information, will send it later if any.

Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Update WindowSizeDifferentScreens.java
 - Update ListMultipleSelectTest.java
 - syncBounds code reformat
 - javadoc fix for SunGraphicsEnvironment#toDeviceSpace
 - Merge branch 'master' into JDK-8211999
 - Apply suggestions from code review

   Co-authored-by: Aleksei Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Merge branch 'master' into JDK-8211999
 - Update FullscreenWindowProps.java
 - Merge branch 'master' into JDK-8211999
 - Fix fullscreen in HiDPI mode
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/1a5e6c98...636b7cc4

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

Changes: https://git.openjdk.java.net/jdk/pull/375/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=375&range=03
  Stats: 1391 lines in 35 files changed: 962 ins; 276 del; 153 mod
  Patch: https://git.openjdk.java.net/jdk/pull/375.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/375/head:pull/375

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

From serb at openjdk.java.net  Wed Oct 28 23:46:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 23:46:59 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Oct 2020 16:24:20 GMT, Alexey Ivanov  wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8211999
>>  - Update FullscreenWindowProps.java
>>  - Merge branch 'master' into JDK-8211999
>>  - Fix fullscreen in HiDPI mode
>>  - self review
>>  - Initial fix version
>
> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 445:
> 
>> 443:      * @return the point which uses device space(pixels)
>> 444:      */
>> 445:     public static Point toDeviceSpace(int x, int y) {
> 
> Does this function converts _absolute_ coordinates?
> I see it uses a different formula to convert: the coordinates are scaled as opposed to `-Abs` set of functions.

fixed, the javadoc is updated.

> src/java.desktop/windows/classes/sun/awt/windows/WWindowPeer.java line 311:
> 
>> 309: 
>> 310:     final void syncBounds(){
>> 311:         // The Windows will take care of the top-level window/frame/dialog,
> 
> Suggestion:
> 
>     final void syncBounds() {
>         // Windows will take care of the top-level window/frame/dialog,
> 
> Does it override another implementation of `syncBounds()`? Or does it implement a method in an interface?
> Shall it have `@Override` annotation?

fixed, @Override is added

> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3987:
> 
>> 3985: }
>> 3986: 
>> 3987: } /* extern "C" */
> 
> Probably, it's better to preserve the line end at the end of the file.

fixed

> test/jdk/java/awt/List/ListMultipleSelectTest/ListMultipleSelectTest.java line 90:
> 
>> 88:             for (int i = 0; i < aList.getItemCount(); i++) {
>> 89:                 //select all items in the List
>> 90:                 mousePress(p.x + listSize.height / 2, p.y + stepY / 2 + stepY * i);
> 
> x be based on width?
>                 mousePress(p.x + listSize.width / 2, p.y + stepY / 2 + stepY * i);

fixed

> test/jdk/java/awt/Window/WindowSizeDifferentScreens/WindowSizeDifferentScreens.java line 110:
> 
>> 108:             case "dialog" -> new Dialog((Dialog) null);
>> 109:             case "frame" -> new Frame();
>> 110:             default -> throw new IllegalStateException("Unexpected: " + top);
> 
> `IllegalArgumentException` more appropriate?
>             default -> throw new IllegalArgumentException("Unexpected: " + top);

fixed

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

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

From serb at openjdk.java.net  Wed Oct 28 23:54:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Wed, 28 Oct 2020 23:54:55 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Oct 2020 20:44:01 GMT, Alexey Ivanov  wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8211999
>>  - Update FullscreenWindowProps.java
>>  - Merge branch 'master' into JDK-8211999
>>  - Fix fullscreen in HiDPI mode
>>  - self review
>>  - Initial fix version
>
> test/jdk/javax/swing/JTextArea/8149849/DNDTextToScaledArea.java line 81:
> 
>> 79:         robot.mousePress(InputEvent.BUTTON1_MASK);
>> 80:         robot.mouseRelease(InputEvent.BUTTON1_MASK);
>> 81:         robot.waitForIdle();
> 
> Why is clicking the `dstTextArea` required?

Mostly to make window active, when I stress testing the fix, this test rarely fails(before and after the fix) I think due to the window appeared inactive and DnD did not start/not complete.

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

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

From serb at openjdk.java.net  Thu Oct 29 00:03:49 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 29 Oct 2020 00:03:49 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI) [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 28 Oct 2020 17:34:07 GMT, Alexey Ivanov  wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8211999
>>  - Update FullscreenWindowProps.java
>>  - Merge branch 'master' into JDK-8211999
>>  - Fix fullscreen in HiDPI mode
>>  - self review
>>  - Initial fix version
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2217:
> 
>> 2215:                     y = y < bounds.top ? bounds.top : y;
>> 2216:                     x = (x + w > bounds.right) ? bounds.right - w : x;
>> 2217:                     y = (y + h > bounds.bottom) ? bounds.bottom - h : y;
> 
> Can't this adjustment cause `x`, `y` to become less than `bounds.left` and `bounds.top` correspondingly?
> Shall it adjust the width and height?

Yes, if the size of the window is bigger than the screen it will be moved to the left. I am not sure is it good to scale down the size in this case or not, so I left the logic the same as before. These lines are not new, only whitespaces are changed.

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

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

From kizune at openjdk.java.net  Thu Oct 29 17:58:43 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 29 Oct 2020 17:58:43 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI)
In-Reply-To: 
References: 

Message-ID: 

On Fri, 2 Oct 2020 16:47:37 GMT, Victor Dyakov  wrote:

>> @prsadhuk  can you review this?
>
> @prrace Can you review this?

I'm trying to test these changes but i have weird problems with mouse event coordinate translation. For example - i have two displays side by side with some vertical shift and with different scale factor. After this fix if the window spans across multiple monitors when i move cursor over the part on the secondary monitor related to the main window position mouse events got sent to the wrong component. Look at the attached image - by the position of the tooltip you can see that the mouse is hovering over the menu bar area - namely over "Options" menu, yet the tooltip is from the JProgressBar demo and if you look at the toolbar you will see JProgressBar demo button highlighted as if mouse is on top of it. And if i click instead of selecting the menu the button got pressed. Not sure why it happens but seems like it was not happened before the fix.
![events](https://user-images.githubusercontent.com/69642324/97612555-cf808680-19d4-11eb-9707-9eeb22b196d0.PNG)

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

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

From serb at openjdk.java.net  Thu Oct 29 23:41:46 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 29 Oct 2020 23:41:46 GMT
Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to
 overlapping GraphicsDevice bounds (Windows/HiDPI)
In-Reply-To: 
References: 

Message-ID: 

On Thu, 29 Oct 2020 17:55:36 GMT, Alexander Zuev  wrote:

>> @prrace Can you review this?
>
> I'm trying to test these changes but i have weird problems with mouse event coordinate translation. For example - i have two displays side by side with some vertical shift and with different scale factor. After this fix if the window spans across multiple monitors when i move cursor over the part on the secondary monitor related to the main window position mouse events got sent to the wrong component. Look at the attached image - by the position of the tooltip you can see that the mouse is hovering over the menu bar area - namely over "Options" menu, yet the tooltip is from the JProgressBar demo and if you look at the toolbar you will see JProgressBar demo button highlighted as if mouse is on top of it. And if i click instead of selecting the menu the button got pressed. Not sure why it happens but seems like it was not happened before the fix.
> ![events](https://user-images.githubusercontent.com/69642324/97612555-cf808680-19d4-11eb-9707-9eeb22b196d0.PNG)

You found this bug https://bugs.openjdk.java.net/browse/JDK-8249164 the case when the window is split across two screens with different DPI are not properly supported before and after the fix, in both cases, there are values which break it. But I need to confirm that, please provide exact display resolution/java pipeline/and scales.
BTW this is the case why thr JUMP TO machinery was added to the "awt_Window.cpp"

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

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