From serb at openjdk.java.net Mon Nov 2 03:59:06 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Nov 2020 03:59:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255722: Create a new test for rotated blit Message-ID: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> I have worked on a possible improvement in the OGL blit logic, and right before PR creation found a critical bug that ruined the whole idea of the change. Unfortunately, non of the tests found this bug, so instead of a fix, I propose a new test that will be able to find such issues in the future(actually it already caught the bug in XRender https://bugs.openjdk.java.net/browse/JDK-8255724) The test works fine for GDI, OpenGL, d3d, and x11 pipelines. ------------- Commit messages: - Update BlitRotateClippedArea.java - Update ProblemList.txt - Update BlitRotateClippedArea.java - Create BlitRotateClippedArea.java Changes: https://git.openjdk.java.net/jdk/pull/991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=991&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255722 Stats: 143 lines in 2 files changed: 143 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/991/head:pull/991 PR: https://git.openjdk.java.net/jdk/pull/991 From prr at openjdk.java.net Mon Nov 2 04:29:10 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 04:29:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race wrote: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Aside from the code change there is a small build change is to remove some obsolete defines ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Mon Nov 2 04:29:10 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 04:29:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 Message-ID: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library https://bugs.openjdk.java.net/browse/JDK-8247872 This has passed building and headless and headful automated tests on all platforms. ------------- Commit messages: - 8247872: Upgrade HarfBuzz to the latest 2.7.2 Changes: https://git.openjdk.java.net/jdk/pull/993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247872 Stats: 44663 lines in 207 files changed: 25198 ins; 12729 del; 6736 mod Patch: https://git.openjdk.java.net/jdk/pull/993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/993/head:pull/993 PR: https://git.openjdk.java.net/jdk/pull/993 From serb at openjdk.java.net Mon Nov 2 09:18:04 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Nov 2020 09:18:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211958: Broken links in java.desktop files In-Reply-To: References: Message-ID: <419qL9UPahnCzXx_oOMJVGD_ZT3xVzvYCz7M4m0hTBE=.0cd2c408-3de5-4baf-866c-407219a4c96c@github.com> On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov wrote: > Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817 > This change fix just a few. > > Also two cleanups are applied: > - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/` > - The html links to the java classes via `` replaced by the `{@link }` src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html line 101: > 99: > 100: The return value is a > 101: Map of Broken link to Map. src/java.desktop/share/classes/javax/print/DocFlavor.java line 159: > 157: * common flavors, the pre-defined *HOST {@code DocFlavors} may be used. > 158: *

> 159: * See character Broken link to the java.base module ------------- PR: https://git.openjdk.java.net/jdk/pull/998 From serb at openjdk.java.net Mon Nov 2 09:18:03 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Nov 2020 09:18:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211958: Broken links in java.desktop files Message-ID: Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817 This change fix just a few. Also two cleanups are applied: - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/` - The html links to the java classes via `` replaced by the `{@link }` ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/998/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=998&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8211958 Stats: 43 lines in 9 files changed: 0 ins; 4 del; 39 mod Patch: https://git.openjdk.java.net/jdk/pull/998.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/998/head:pull/998 PR: https://git.openjdk.java.net/jdk/pull/998 From ihse at openjdk.java.net Mon Nov 2 12:35:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Mon, 2 Nov 2020 12:35:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race wrote: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Build changes look good. I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? (I could not even add review comments to an empty file in github! ??) ------------- Marked as reviewed by ihse (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/993 From aivanov at openjdk.java.net Mon Nov 2 13:17:58 2020 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 2 Nov 2020 13:17:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211958: Broken links in java.desktop files In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov wrote: > Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817 > This change fix just a few. > > Also two cleanups are applied: > - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/` > - The html links to the java classes via `` replaced by the `{@link }` Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/998 From prr at openjdk.java.net Mon Nov 2 16:28:22 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 16:28:22 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v2] In-Reply-To: References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> On Mon, 2 Nov 2020 12:33:17 GMT, Magnus Ihse Bursie wrote: > I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... > > If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? > > (I could not even add review comments to an empty file in github! ??) oops. that should not have been in that folder. It was me practicing a different white space removal script. I thought I checked for any extraneous files. I'll get rid of it now. ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Mon Nov 2 16:28:22 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 2 Nov 2020 16:28:22 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v2] In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8247872: Upgrade HarfBuzz to the latest 2.7.2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/993/files - new: https://git.openjdk.java.net/jdk/pull/993/files/8d1ea467..1f47957b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=00-01 Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/993/head:pull/993 PR: https://git.openjdk.java.net/jdk/pull/993 From serb at openjdk.java.net Mon Nov 2 19:38:04 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 2 Nov 2020 19:38:04 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8211958: Broken links in java.desktop files In-Reply-To: References: Message-ID: On Mon, 2 Nov 2020 09:04:39 GMT, Sergey Bylokhov wrote: > Most of the broken links were fixed already by the JDK-8225368 and JDK-8214817 > This change fix just a few. > > Also two cleanups are applied: > - The `../../java/awt/doc-files/` in some cases simplified to `doc-files/` > - The html links to the java classes via `` replaced by the `{@link }` This pull request has now been integrated. Changeset: acb5f654 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/acb5f654 Stats: 43 lines in 9 files changed: 0 ins; 4 del; 39 mod 8211958: Broken links in java.desktop files Reviewed-by: aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/998 From github.com+1538227+arodionov at openjdk.java.net Wed Nov 4 23:11:58 2020 From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov) Date: Wed, 4 Nov 2020 23:11:58 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 @mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above. The general steps: - download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image - build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample` - run built image - it should be executed successfully - clone any version of the OpenJDK (11.09 - 16) - build static libraries by executing `make static-libs-image` target - replace `libawt.a` in GraalVM on built static library from OpenJDK - try to build example again and run it - it should be failed - clone OpenJDK with the proposed fix - build static libraries - replace `libawt.a` in GraalVM on built static library with the fix - build example and run it - it should be executed successfully public class AWTFixExample { public static void main(String[] args) { 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); BufferedImage image = op.filter(src, dest); System.out.println(image); } } [configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip) ------------- PR: https://git.openjdk.java.net/jdk/pull/562 From serb at openjdk.java.net Thu Nov 5 01:40:04 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 5 Nov 2020 01:40:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255575: java.awt.color.ICC_ColorSpace is not thread-safe Message-ID: The ICC_ColorSpace class uses a couple of internal data caches that might be used w/o any synchronization by different threads. The solution is to wrap the initialization of the cached data by the DLC. I have checked performance impact by the J2DBench and it seems no big difference before/after the fix. BTW jdk16 in some cases x10 times faster than 8u and 11u. Probably we should backport something, will check that. ------------- Commit messages: - Update ICC_ColorSpace.java - Update MTICC_ColorSpaceToFrom.java - Update ICC_ColorSpace.java - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1069/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1069&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255575 Stats: 182 lines in 2 files changed: 114 ins; 4 del; 64 mod Patch: https://git.openjdk.java.net/jdk/pull/1069.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1069/head:pull/1069 PR: https://git.openjdk.java.net/jdk/pull/1069 From serb at openjdk.java.net Thu Nov 5 07:22:00 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 5 Nov 2020 07:22:00 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255920: J2DBench should support CS_PYCC color profile Message-ID: Support of the CS_PYCC color profile is added to the J2DBench. ------------- Commit messages: - Update CMMTests.java Changes: https://git.openjdk.java.net/jdk/pull/1072/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1072&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255920 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1072.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1072/head:pull/1072 PR: https://git.openjdk.java.net/jdk/pull/1072 From serb at openjdk.java.net Thu Nov 5 11:06:05 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 5 Nov 2020 11:06:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255937: Better cleanup for test/jdk/javax/imageio/stream/StreamFlush.java Message-ID: <6qcuM2ebehbXXW05eHRK7jRWngzoAC5RrYFrenvi8UA=.0b93148a-f414-4925-80ec-6e03e9da6dd5@github.com> The test leaves two temporary files due to unclosed file streams. ------------- Commit messages: - Update StreamFlush.java Changes: https://git.openjdk.java.net/jdk/pull/1074/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1074&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255937 Stats: 19 lines in 1 file changed: 11 ins; 3 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/1074.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1074/head:pull/1074 PR: https://git.openjdk.java.net/jdk/pull/1074 From jdv at openjdk.java.net Thu Nov 5 11:17:58 2020 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 5 Nov 2020 11:17:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255937: Better cleanup for test/jdk/javax/imageio/stream/StreamFlush.java In-Reply-To: <6qcuM2ebehbXXW05eHRK7jRWngzoAC5RrYFrenvi8UA=.0b93148a-f414-4925-80ec-6e03e9da6dd5@github.com> References: <6qcuM2ebehbXXW05eHRK7jRWngzoAC5RrYFrenvi8UA=.0b93148a-f414-4925-80ec-6e03e9da6dd5@github.com> Message-ID: On Thu, 5 Nov 2020 09:06:39 GMT, Sergey Bylokhov wrote: > The test leaves two temporary files due to unclosed file streams. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1074 From serb at openjdk.java.net Thu Nov 5 11:26:57 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 5 Nov 2020 11:26:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v2] In-Reply-To: <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> Message-ID: On Mon, 2 Nov 2020 16:23:19 GMT, Phil Race wrote: >> I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... >> >> If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? >> >> (I could not even add review comments to an empty file in github! ??) > >> I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... >> >> If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? >> >> (I could not even add review comments to an empty file in github! ??) > > oops. that should not have been in that folder. It was me practicing a different white space removal script. > I thought I checked for any extraneous files. I'll get rid of it now. Looks like the build on macOS via GitHub will be broken by this fix? ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From serb at openjdk.java.net Thu Nov 5 11:39:58 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 5 Nov 2020 11:39:58 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8255937: Better cleanup for test/jdk/javax/imageio/stream/StreamFlush.java In-Reply-To: <6qcuM2ebehbXXW05eHRK7jRWngzoAC5RrYFrenvi8UA=.0b93148a-f414-4925-80ec-6e03e9da6dd5@github.com> References: <6qcuM2ebehbXXW05eHRK7jRWngzoAC5RrYFrenvi8UA=.0b93148a-f414-4925-80ec-6e03e9da6dd5@github.com> Message-ID: <7wWzF-Ruao65E4oXEGSXNI__jKO7KOFYg02JsuInpkU=.4cfc07e0-f82c-4abc-b3ad-7a3d78cc4426@github.com> On Thu, 5 Nov 2020 09:06:39 GMT, Sergey Bylokhov wrote: > The test leaves two temporary files due to unclosed file streams. This pull request has now been integrated. Changeset: d3c43c28 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/d3c43c28 Stats: 19 lines in 1 file changed: 11 ins; 3 del; 5 mod 8255937: Better cleanup for test/jdk/javax/imageio/stream/StreamFlush.java Reviewed-by: jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/1074 From ihse at openjdk.java.net Thu Nov 5 13:38:57 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 5 Nov 2020 13:38:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v2] In-Reply-To: References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> Message-ID: On Thu, 5 Nov 2020 11:24:28 GMT, Sergey Bylokhov wrote: >>> I'm just a bit curious about the added, empty, `src/java.desktop/share/native/libharfbuzz/abc.txt`... >>> >>> If it really is in upstream source, I'm not saying you should remove it. It just looks very odd. It's not a merge artifact? >>> >>> (I could not even add review comments to an empty file in github! ??) >> >> oops. that should not have been in that folder. It was me practicing a different white space removal script. >> I thought I checked for any extraneous files. I'll get rid of it now. > > Looks like the build on macOS via GitHub will be broken by this fix? @mrserb Good catch! Yes indeed, it looks like `range-loop-analysis` needs to be disabled for clang for Xcode 12 to not complain. ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Thu Nov 5 17:52:19 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 Nov 2020 17:52:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v3] In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8247872: Upgrade HarfBuzz to the latest 2.7.2 ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/993/files - new: https://git.openjdk.java.net/jdk/pull/993/files/1f47957b..3d172716 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=993&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/993/head:pull/993 PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Thu Nov 5 17:55:59 2020 From: prr at openjdk.java.net (Phil Race) Date: Thu, 5 Nov 2020 17:55:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v3] In-Reply-To: References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> Message-ID: On Thu, 5 Nov 2020 13:36:18 GMT, Magnus Ihse Bursie wrote: >> Looks like the build on macOS via GitHub will be broken by this fix? > > @mrserb Good catch! Yes indeed, it looks like `range-loop-analysis` needs to be disabled for clang for Xcode 12 to not complain. I added that to the disabled warnings .. now I suppose the actions will re-run but I don't see any sign of it yet. Just that the results that were there are now gone. A few thoughts on this - github sends so many messages that it is easy to miss the important ones - using the default for github we are at the whim of when ever they switch and if this change had been pushed 6 weeks ago likely it would have passed until the day github upgraded. - it also means passing a github build does not guarantee it will pass on the "official" toolchains. ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From ihse at openjdk.java.net Thu Nov 5 23:55:56 2020 From: ihse at openjdk.java.net (Magnus Ihse Bursie) Date: Thu, 5 Nov 2020 23:55:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v3] In-Reply-To: References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <2um9af6839x1BDDn3P10xB6WcxXVc_DGAjCDueyfDcI=.5feeee81-b628-465a-8123-3750ea4db3d2@github.com> Message-ID: On Thu, 5 Nov 2020 17:52:53 GMT, Phil Race wrote: >> @mrserb Good catch! Yes indeed, it looks like `range-loop-analysis` needs to be disabled for clang for Xcode 12 to not complain. > > I added that to the disabled warnings .. now I suppose the actions will re-run but I don't see any sign of it yet. > Just that the results that were there are now gone. > A few thoughts on this > - github sends so many messages that it is easy to miss the important ones > - using the default for github we are at the whim of when ever they switch and if this change > had been pushed 6 weeks ago likely it would have passed until the day github upgraded. > - it also means passing a github build does not guarantee it will pass on the "official" toolchains. @prrace I agree, the github actions are a double-edged sword -- at best. At worst, it's a clear regression in terms of how we work. :-( We might need to take a step back and rethink this. Anyway, your changes looks good from a build PoV now. ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From serb at openjdk.java.net Sat Nov 7 01:45:09 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 7 Nov 2020 01:45:09 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255722: Create a new test for rotated blit [v2] In-Reply-To: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> References: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> Message-ID: > I have worked on a possible improvement in the OGL blit logic, and right before PR creation found a critical bug that ruined the whole idea of the change. Unfortunately, non of the tests found this bug, so instead of a fix, I propose a new test that will be able to find such issues in the future(actually it already caught the bug in XRender https://bugs.openjdk.java.net/browse/JDK-8255724) > > The test works fine for GDI, OpenGL, d3d, and x11 pipelines. 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-8255722 - Update BlitRotateClippedArea.java - Update BlitRotateClippedArea.java - Update ProblemList.txt - Update BlitRotateClippedArea.java - Create BlitRotateClippedArea.java ------------- Changes: https://git.openjdk.java.net/jdk/pull/991/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=991&range=01 Stats: 143 lines in 2 files changed: 143 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/991.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/991/head:pull/991 PR: https://git.openjdk.java.net/jdk/pull/991 From serb at openjdk.java.net Sun Nov 8 10:23:54 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 8 Nov 2020 10:23:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 [v3] In-Reply-To: References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Thu, 5 Nov 2020 17:52:19 GMT, Phil Race wrote: >> This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library >> >> https://bugs.openjdk.java.net/browse/JDK-8247872 >> >> This has passed building and headless and headful automated tests on all platforms. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8247872: Upgrade HarfBuzz to the latest 2.7.2 Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Sun Nov 8 17:08:56 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 17:08:56 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: On Mon, 2 Nov 2020 04:19:57 GMT, Phil Race wrote: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on all platforms. This pull request has now been integrated. Changeset: ed7526a6 Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/ed7526a6 Stats: 44664 lines in 206 files changed: 25198 ins; 12729 del; 6737 mod 8247872: Upgrade HarfBuzz to the latest 2.7.2 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/993 From prr at openjdk.java.net Sun Nov 8 21:44:54 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:44:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255920: J2DBench should support CS_PYCC color profile In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 07:15:32 GMT, Sergey Bylokhov wrote: > Support of the CS_PYCC color profile is added to the J2DBench. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1072 From prr at openjdk.java.net Sun Nov 8 21:48:55 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:48:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255575: java.awt.color.ICC_ColorSpace is not thread-safe In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 01:34:25 GMT, Sergey Bylokhov wrote: > The ICC_ColorSpace class uses a couple of internal data caches that might be used w/o any synchronization by different threads. > > The solution is to wrap the initialization of the cached data by the DLC. I have checked performance impact by the J2DBench and it seems no big difference before/after the fix. > > BTW jdk16 in some cases x10 times faster than 8u and 11u. Probably we should backport something, will check that. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1069 From prr at openjdk.java.net Sun Nov 8 21:49:59 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:49:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255722: Create a new test for rotated blit [v2] In-Reply-To: References: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> Message-ID: On Sat, 7 Nov 2020 01:45:09 GMT, Sergey Bylokhov wrote: >> I have worked on a possible improvement in the OGL blit logic, and right before PR creation found a critical bug that ruined the whole idea of the change. Unfortunately, non of the tests found this bug, so instead of a fix, I propose a new test that will be able to find such issues in the future(actually it already caught the bug in XRender https://bugs.openjdk.java.net/browse/JDK-8255724) >> >> The test works fine for GDI, OpenGL, d3d, and x11 pipelines. > > 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-8255722 > - Update BlitRotateClippedArea.java > - Update BlitRotateClippedArea.java > - Update ProblemList.txt > - Update BlitRotateClippedArea.java > - Create BlitRotateClippedArea.java Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/991 From prr at openjdk.java.net Sun Nov 8 21:51:54 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:51:54 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: <9pa4tze1UtM2toYkdG9okeVxDITw5hznsz7iImcKc38=.da472089-79e5-471a-bc69-cc430938af27@github.com> 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. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/870 From prr at openjdk.java.net Sun Nov 8 21:55:55 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:55:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 4619330: some of java.awt.color.ColorSpace fields should specified that build-in In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 22:32:15 GMT, Sergey Bylokhov wrote: > The wording for ColorSpace.CS_XXX is unified. The change is fine but please update the commit message of the PR to match the updated synopsis of the bug report. It wasn't even a complete sentence. ------------- Marked as reviewed by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/887 From prr at openjdk.java.net Sun Nov 8 21:59:56 2020 From: prr at openjdk.java.net (Phil Race) Date: Sun, 8 Nov 2020 21:59:56 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() I don't think it was really for kernel. The Windows on-line jRE installer made it an optional component. Marked as reviewed by prr (Reviewer). ------------- Changes requested by prr (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/691 From serb at openjdk.java.net Mon Nov 9 01:15:57 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Nov 2020 01:15:57 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8255722: Create a new test for rotated blit In-Reply-To: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> References: <6V2-PBt42Qib3FMZIeOCGHIltmWXfmdhUKrrrJ84OCo=.743fa501-b88b-4fc9-b103-0e707defa2b9@github.com> Message-ID: On Mon, 2 Nov 2020 02:58:09 GMT, Sergey Bylokhov wrote: > I have worked on a possible improvement in the OGL blit logic, and right before PR creation found a critical bug that ruined the whole idea of the change. Unfortunately, non of the tests found this bug, so instead of a fix, I propose a new test that will be able to find such issues in the future(actually it already caught the bug in XRender https://bugs.openjdk.java.net/browse/JDK-8255724) > > The test works fine for GDI, OpenGL, d3d, and x11 pipelines. This pull request has now been integrated. Changeset: a53b12df Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/a53b12df Stats: 143 lines in 2 files changed: 143 ins; 0 del; 0 mod 8255722: Create a new test for rotated blit Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/991 From serb at openjdk.java.net Mon Nov 9 01:30:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Nov 2020 01:30:59 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8255575: java.awt.color.ICC_ColorSpace is not thread-safe In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 01:34:25 GMT, Sergey Bylokhov wrote: > The ICC_ColorSpace class uses a couple of internal data caches that might be used w/o any synchronization by different threads. > > The solution is to wrap the initialization of the cached data by the DLC. I have checked performance impact by the J2DBench and it seems no big difference before/after the fix. > > BTW jdk16 in some cases x10 times faster than 8u and 11u. Probably we should backport something, will check that. This pull request has now been integrated. Changeset: 2cad8368 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/2cad8368 Stats: 182 lines in 2 files changed: 114 ins; 4 del; 64 mod 8255575: java.awt.color.ICC_ColorSpace is not thread-safe Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/1069 From serb at openjdk.java.net Mon Nov 9 01:41:56 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Nov 2020 01:41:56 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8255920: J2DBench should support CS_PYCC color profile In-Reply-To: References: Message-ID: On Thu, 5 Nov 2020 07:15:32 GMT, Sergey Bylokhov wrote: > Support of the CS_PYCC color profile is added to the J2DBench. This pull request has now been integrated. Changeset: 3ce09c05 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/3ce09c05 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8255920: J2DBench should support CS_PYCC color profile Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/1072 From serb at openjdk.java.net Mon Nov 9 06:39:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Nov 2020 06:39:59 GMT Subject: [OpenJDK 2D-Dev] Integrated: 6847157: java.lang.NullPointerException: HDC for component at sun.java2d.loops.Blit.Blit In-Reply-To: References: Message-ID: <9WZ-kwNDHofanThX6JmcZF1a8tPO1OOCg25CXXXwdYc=.698a17f0-4ddf-4618-a8e7-5c73892be27b@github.com> 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. This pull request has now been integrated. Changeset: 2d6c28db Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/2d6c28db Stats: 94 lines in 2 files changed: 93 ins; 0 del; 1 mod 6847157: java.lang.NullPointerException: HDC for component at sun.java2d.loops.Blit.Blit Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/870 From serb at openjdk.java.net Mon Nov 9 23:43:00 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 9 Nov 2020 23:43:00 GMT Subject: [OpenJDK 2D-Dev] Integrated: 4619330: All built-in java.awt.color.ColorSpace fields should be specified as such In-Reply-To: References: Message-ID: On Tue, 27 Oct 2020 22:32:15 GMT, Sergey Bylokhov wrote: > The wording for ColorSpace.CS_XXX is unified. This pull request has now been integrated. Changeset: 11431b16 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/11431b16 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod 4619330: All built-in java.awt.color.ColorSpace fields should be specified as such Reviewed-by: prr ------------- PR: https://git.openjdk.java.net/jdk/pull/887 From serb at openjdk.java.net Tue Nov 10 01:11:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 01:11:59 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 Wed, 4 Nov 2020 23:09:14 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 > > @mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above. > The general steps: > - download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image > - build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): > `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample` > - run built image - it should be executed successfully > - clone any version of the OpenJDK (11.09 - 16) > - build static libraries by executing `make static-libs-image` target > - replace `libawt.a` in GraalVM on built static library from OpenJDK > - try to build example again and run it - it should be failed > - clone OpenJDK with the proposed fix > - build static libraries > - replace `libawt.a` in GraalVM on built static library with the fix > - build example and run it - it should be executed successfully > > public class AWTFixExample { > public static void main(String[] args) { > 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); > > BufferedImage image = op.filter(src, dest); > System.out.println(image); > } > } > > [configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip) I think part of the changed code is actually dead code and can be removed, I'll take a look. ------------- PR: https://git.openjdk.java.net/jdk/pull/562 From serb at openjdk.java.net Tue Nov 10 06:22:18 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 06:22:18 GMT Subject: [OpenJDK 2D-Dev] Integrated: 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() This pull request has now been integrated. Changeset: b5d78afe Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/b5d78afe Stats: 64 lines in 5 files changed: 2 ins; 52 del; 10 mod 8254863: Delete code leftover from old fixes Reviewed-by: azeemj, kizune, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/691 From serb at openjdk.java.net Tue Nov 10 08:31:04 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 08:31:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU Message-ID: This is a review request for the bug particularly fixed some time ago: https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html In that review request it was found that the old fix does not work well in all cases, see: https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html The current fix updates an embedded plist.info, so the java will not require discrete graphics by default, same as for any other applications. The discrete card will be used: 1. If macOS decided to enable it for some reason 2. If the java app sets/uses a full-screen window 3. If the user disable "automatic graphics switching" in the system preferences 4. If an external monitor is connected to the laptop In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. Note that the new "metal" pipeline also does not require discrete graphics. The documentation for NSSupportsAutomaticGraphicsSwitching: https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching I'll create a release note after approval. Performance numbers: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html Old review request: https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1139/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1139&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8251854 Stats: 6 lines in 3 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/1139.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1139/head:pull/1139 PR: https://git.openjdk.java.net/jdk/pull/1139 From kizune at openjdk.java.net Tue Nov 10 09:19:59 2020 From: kizune at openjdk.java.net (Alexander Zuev) Date: Tue, 10 Nov 2020 09:19:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4] In-Reply-To: References: Message-ID: On Wed, 28 Oct 2020 23:46:55 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 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 Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From aivanov at openjdk.java.net Tue Nov 10 09:54:59 2020 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 10 Nov 2020 09:54:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4] In-Reply-To: References: Message-ID: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com> On Wed, 28 Oct 2020 23:46:55 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 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 Marked as reviewed by aivanov (Reviewer). src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357: > 355: * @param config the graphics configuration which bounds are requested > 356: * @return the bounds of the area covered by this > 357: * {@code GraphicsConfiguration} in device space(pixels). Suggestion: * {@code GraphicsConfiguration} in device space (pixels). If changed here, all other similar places should be updated too to keep doc comments consistent. ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From kcr at openjdk.java.net Tue Nov 10 12:53:55 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Nov 2020 12:53:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html I'm still somewhat unsure whether we want to do this in all cases. As mentioned offline, the discrete GPU will be unused (might as well not be there) for almost all Java applications when using a single screen. When the MacBook Pro is running on battery, this seems like a good thing, but when it is plugged in, it seems like we wasting the discrete GPU. It's too bad Apple doesn't provide a way for an application to hint whether they would like to use the discrete GPU if available. I want to run some performance tests with JavaFX, since it will likely impact JavaFX applications. ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From erikj at openjdk.java.net Tue Nov 10 13:26:57 2020 From: erikj at openjdk.java.net (Erik Joelsson) Date: Tue, 10 Nov 2020 13:26:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: References: Message-ID: On Tue, 10 Nov 2020 08:19:13 GMT, Sergey Bylokhov wrote: > This is a review request for the bug particularly fixed some time ago: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html > > In that review request it was found that the old fix does not work well in all cases, see: > https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html > > The current fix updates an embedded plist.info, so the java will not require > discrete graphics by default, same as for any other applications. > > The discrete card will be used: > 1. If macOS decided to enable it for some reason > 2. If the java app sets/uses a full-screen window > 3. If the user disable "automatic graphics switching" in the system preferences > 4. If an external monitor is connected to the laptop > > In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. > > > Note that the new "metal" pipeline also does not require discrete graphics. > > The documentation for NSSupportsAutomaticGraphicsSwitching: > https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching > > I'll create a release note after approval. > > Performance numbers: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html > Old review request: > https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. ------------- Marked as reviewed by erikj (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1139 From kcr at openjdk.java.net Tue Nov 10 16:40:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Tue, 10 Nov 2020 16:40:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: References: Message-ID: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> On Tue, 10 Nov 2020 13:24:21 GMT, Erik Joelsson wrote: >> This is a review request for the bug particularly fixed some time ago: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-May/005425.html >> >> In that review request it was found that the old fix does not work well in all cases, see: >> https://mail.openjdk.java.net/pipermail/2d-dev/2015-August/005611.html >> >> The current fix updates an embedded plist.info, so the java will not require >> discrete graphics by default, same as for any other applications. >> >> The discrete card will be used: >> 1. If macOS decided to enable it for some reason >> 2. If the java app sets/uses a full-screen window >> 3. If the user disable "automatic graphics switching" in the system preferences >> 4. If an external monitor is connected to the laptop >> >> In other cases, the integrated graphics will be used, which should be fine in most cases since this graphic is used/tested in the mbp 13/etc. This is not only about rendering performance but also about startup performance, on my current new laptop mbp 16 + Cataline 10.15.7 the switching discrete/integrated causes unexpected delays up to 10 seconds. >> >> >> Note that the new "metal" pipeline also does not require discrete graphics. >> >> The documentation for NSSupportsAutomaticGraphicsSwitching: >> https://developer.apple.com/documentation/bundleresources/information_property_list/nssupportsautomaticgraphicsswitching >> >> I'll create a release note after approval. >> >> Performance numbers: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010979.html >> Old review request: >> https://mail.openjdk.java.net/pipermail/2d-dev/2020-August/010973.html > > Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: **attenuation.LightingSample: 500 large quads** discrete GPU: 23.5 fps integrated GPU: 2.34 fps In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: **Vector charting test, oval clip** discrete GPU: 41.1 fps integrated GPU: 26.6 fps I see similar results in the performance numbers you listed above. An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From serb at openjdk.java.net Tue Nov 10 17:17:58 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 17:17:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> References: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> Message-ID: On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. The difference between the two is that, if the integrated card is default then it is possible to force the discrete card if needed, but it is not possible to force the integrated card if discrete is the default. In the end, it is a laptop, it will work longer on an integrated card. ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From serb at openjdk.java.net Tue Nov 10 18:44:00 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 18:44:00 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4] In-Reply-To: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com> References: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com> Message-ID: On Tue, 10 Nov 2020 09:33:22 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 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 > > src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357: > >> 355: * @param config the graphics configuration which bounds are requested >> 356: * @return the bounds of the area covered by this >> 357: * {@code GraphicsConfiguration} in device space(pixels). > > Suggestion: > > * {@code GraphicsConfiguration} in device space (pixels). > If changed here, all other similar places should be updated too to keep doc comments consistent. I'll fix it and also merge the master, then update the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From aivanov at openjdk.java.net Tue Nov 10 19:38:58 2020 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 10 Nov 2020 19:38:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4] In-Reply-To: References: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com> Message-ID: On Tue, 10 Nov 2020 18:40:45 GMT, Sergey Bylokhov wrote: >> src/java.desktop/share/classes/sun/java2d/SunGraphicsEnvironment.java line 357: >> >>> 355: * @param config the graphics configuration which bounds are requested >>> 356: * @return the bounds of the area covered by this >>> 357: * {@code GraphicsConfiguration} in device space(pixels). >> >> Suggestion: >> >> * {@code GraphicsConfiguration} in device space (pixels). >> If changed here, all other similar places should be updated too to keep doc comments consistent. > > I'll fix it and also merge the master, then update the PR. In this case, also consider adding a space between the word and the opening parenthesis in these _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma. ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From serb at openjdk.java.net Tue Nov 10 20:38:12 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 20:38:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v5] 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 14 commits: - Update SunGraphicsEnvironment.java - Merge branch 'master' into JDK-8211999 - 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 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a7f46919...fd238ef6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/375/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=375&range=04 Stats: 1393 lines in 35 files changed: 962 ins; 276 del; 155 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 Tue Nov 10 20:38:12 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 10 Nov 2020 20:38:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) [v4] In-Reply-To: References: <5LNG6nKhwE5XoKjIS9E8Sr5x0IxcFYUcszeGcEck87s=.5d5bb638-c044-4b75-899d-758ed21b872e@github.com> Message-ID: On Tue, 10 Nov 2020 19:35:58 GMT, Alexey Ivanov wrote: >> I'll fix it and also merge the master, then update the PR. > > In this case, also consider adding a space between the word and the opening parenthesis in these _coordinates (x, y)_ and _size (w, h)_ and, probably, a space after comma. Spaces are added. ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From serb at openjdk.java.net Wed Nov 11 01:34:57 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 11 Nov 2020 01:34:57 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) In-Reply-To: References: Message-ID: <6xdyT0w04J4Q21Cy5LLc2gRnOjyjCHgvDzV6tn9g1KI=.c549d830-c144-4d8e-b4be-464ff836ced0@github.com> On Sun, 27 Sep 2020 22:16:22 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. This pull request has now been integrated. Changeset: be635258 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/be635258 Stats: 1393 lines in 35 files changed: 962 ins; 276 del; 155 mod 8211999: Window positioning bugs due to overlapping GraphicsDevice bounds (Windows/HiDPI) Reviewed-by: kizune, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/375 From alexsch at openjdk.java.net Thu Nov 12 10:37:06 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 12 Nov 2020 10:37:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows Message-ID: Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. The GDI system used for text printing on Windows accepts only integer path coordinates. Rounding GlyphVector outline coordinates leads to distorted printed text. To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by filling GlyphVector outline. Chars on the second line are distorted. It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled scales the GDI WorldTransform down and GlyphVector outline coordinates up. This allows to keep some digits after a dot from being rounded. The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. ------------- Commit messages: - 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows Changes: https://git.openjdk.java.net/jdk/pull/1183/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1183&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256264 Stats: 480 lines in 4 files changed: 469 ins; 0 del; 11 mod Patch: https://git.openjdk.java.net/jdk/pull/1183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1183/head:pull/1183 PR: https://git.openjdk.java.net/jdk/pull/1183 From herrick at openjdk.java.net Thu Nov 12 18:32:02 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 12 Nov 2020 18:32:02 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs preliminary changes for JDK-8189198 for evaluation ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From herrick at openjdk.java.net Thu Nov 12 18:32:02 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 12 Nov 2020 18:32:02 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs Message-ID: JDK-8189198: Add "forRemoval = true" to Applet APIs ------------- Commit messages: - Merge branch 'master' into JDK-8189198 - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs Changes: https://git.openjdk.java.net/jdk/pull/1127/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8189198 Stats: 61 lines in 20 files changed: 10 ins; 0 del; 51 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127 From kcr at openjdk.java.net Thu Nov 12 19:22:01 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Thu, 12 Nov 2020 19:22:01 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 13:57:32 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > preliminary changes for JDK-8189198 for evaluation The following field, which is currently deprecated (not for removal) should probably also be marked as deprecated for removal:: javax.naming.Context: static final String APPLET The CSR and JEP should be updated accordingly. Also, what about the following? javax.swing.text.html.parser.DTD Element applet ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From iris at openjdk.java.net Thu Nov 12 19:40:54 2020 From: iris at openjdk.java.net (Iris Clark) Date: Thu, 12 Nov 2020 19:40:54 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: <1hu3mjRsBg1gnnWXUNl9TQ8PoPFjmGOaXkr6Vdd4mOo=.7ead6f18-6b34-42e4-adfb-756ada49eb61@github.com> On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs Since all APIs in the java.applet package are deprecated "forRemoval = true", consider adding a brief deprecation note to java/applet/package-info.java too. As an example, when all of the APIs in package java.rmi.activation were similarly deprecated in JDK 15, the following note was added: https://docs.oracle.com/en/java/javase/15/docs/api/java.rmi/java/rmi/activation/package-summary.html . Thanks! Iris ------------- Marked as reviewed by iris (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1127 From herrick at openjdk.java.net Thu Nov 12 20:48:13 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Thu, 12 Nov 2020 20:48:13 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2] In-Reply-To: References: Message-ID: > JDK-8189198: Add "forRemoval = true" to Applet APIs Andy Herrick 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: - JDK-8189198: Add "forRemoval = true" to Applet APIs - Merge branch 'master' into JDK-8189198 - Merge branch 'master' into JDK-8189198 - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs - JDK-8189198: Add "forRemoval = true" to Applet APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1127/files - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74deeee..d9850cd8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00-01 Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127 From almatvee at openjdk.java.net Thu Nov 12 23:52:56 2020 From: almatvee at openjdk.java.net (Alexander Matveev) Date: Thu, 12 Nov 2020 23:52:56 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2] In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick 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: > > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - Merge branch 'master' into JDK-8189198 > - Merge branch 'master' into JDK-8189198 > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs Marked as reviewed by almatvee (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From kcr at openjdk.java.net Fri Nov 13 00:27:58 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Nov 2020 00:27:58 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs In-Reply-To: References: Message-ID: On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick wrote: > JDK-8189198: Add "forRemoval = true" to Applet APIs @andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer. ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From alanb at openjdk.java.net Fri Nov 13 09:35:00 2020 From: alanb at openjdk.java.net (Alan Bateman) Date: Fri, 13 Nov 2020 09:35:00 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2] In-Reply-To: References: Message-ID: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com> On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick 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: > > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - Merge branch 'master' into JDK-8189198 > - Merge branch 'master' into JDK-8189198 > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs > - JDK-8189198: Add "forRemoval = true" to Applet APIs src/java.naming/share/classes/javax/naming/Context.java line 1087: > 1085: @Deprecated(since="16", forRemoval=true) > 1086: String APPLET = "java.naming.applet"; > 1087: }; Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work). ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From herrick at openjdk.java.net Fri Nov 13 15:05:15 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 13 Nov 2020 15:05:15 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3] In-Reply-To: References: Message-ID: > JDK-8189198: Add "forRemoval = true" to Applet APIs Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8189198: Add "forRemoval = true" to Applet APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1127/files - new: https://git.openjdk.java.net/jdk/pull/1127/files/d9850cd8..c6ea7714 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01-02 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127 From kcr at openjdk.java.net Fri Nov 13 18:03:59 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Nov 2020 18:03:59 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2] In-Reply-To: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com> References: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com> Message-ID: On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman wrote: >> Andy Herrick 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: >> >> - JDK-8189198: Add "forRemoval = true" to Applet APIs >> - Merge branch 'master' into JDK-8189198 >> - Merge branch 'master' into JDK-8189198 >> - JDK-8189198: Add "forRemoval = true" to Applet APIs >> - JDK-8189198: Add "forRemoval = true" to Applet APIs >> - JDK-8189198: Add "forRemoval = true" to Applet APIs > > src/java.naming/share/classes/javax/naming/Context.java line 1087: > >> 1085: @Deprecated(since="16", forRemoval=true) >> 1086: String APPLET = "java.naming.applet"; >> 1087: }; > > Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work). Good point, since it was in fact deprecated in 9. ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From kcr at openjdk.java.net Fri Nov 13 18:23:02 2020 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 13 Nov 2020 18:23:02 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3] In-Reply-To: References: Message-ID: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com> On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick wrote: >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8189198: Add "forRemoval = true" to Applet APIs src/java.desktop/share/classes/java/applet/package-info.java line 40: > 38: *

> 39: * Deprecated. > 40: * This package has been deprecated and may be removed in a future version of the Java Platform. That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41). ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From herrick at openjdk.java.net Fri Nov 13 18:22:59 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Fri, 13 Nov 2020 18:22:59 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2] In-Reply-To: References: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com> Message-ID: On Fri, 13 Nov 2020 18:01:18 GMT, Kevin Rushforth wrote: >> src/java.naming/share/classes/javax/naming/Context.java line 1087: >> >>> 1085: @Deprecated(since="16", forRemoval=true) >>> 1086: String APPLET = "java.naming.applet"; >>> 1087: }; >> >> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work). > > Good point, since it was in fact deprecated in 9. yes - changed to since="9" this morning ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From serb at openjdk.java.net Fri Nov 13 23:07:08 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 13 Nov 2020 23:07:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class Message-ID: The implementation of ICC_Profile tries to defer loading the data of the color profile, and it uses some predefined values for some profile properties for the standard profiles like sRGB, PYCC, etc. If the application requests profile data then the ICC_Profile class activates the profile and uses properties from that data. Deferring mechanism for all profiles was added in JDK-6793818, but unfortunately, the color profile class was hardcoded incorrectly "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" profiles should use "CLASS_COLORSPACECONVERSION". Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the deferring mechanism still uses "CLASS_DISPLAY". As a result of this bug, the color profile reports different values before/after activations. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1211/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1211&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256321 Stats: 87 lines in 2 files changed: 85 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1211.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1211/head:pull/1211 PR: https://git.openjdk.java.net/jdk/pull/1211 From serb at openjdk.java.net Fri Nov 13 23:29:59 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 13 Nov 2020 23:29:59 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3] In-Reply-To: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com> References: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com> Message-ID: On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth wrote: >> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8189198: Add "forRemoval = true" to Applet APIs > > src/java.desktop/share/classes/java/applet/package-info.java line 40: > >> 38: *

>> 39: * Deprecated. >> 40: * This package has been deprecated and may be removed in a future version of the Java Platform. > > That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41). The deprecation description should point to the new API which might be used instead of the deprecated ones. So the text "deprecated without replacement" was intentionally added, it will be good to preserve it. ------------- PR: https://git.openjdk.java.net/jdk/pull/1127 From serb at openjdk.java.net Sat Nov 14 00:27:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 14 Nov 2020 00:27:55 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 Tue, 10 Nov 2020 01:09:03 GMT, Sergey Bylokhov wrote: >> @mrserb With the last dev build of GraalVM based on JDK 11.09, the bug can be reproduced by the approach that I've mentioned above. >> The general steps: >> - download the [last dev build](https://github.com/graalvm/graalvm-ce-dev-builds/releases) of GraalVM + Native image >> - build the native image for AWTFixExample class (ziped configs for reflection and JNI is attached): >> `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true --native-image-info AWTFixExample` >> - run built image - it should be executed successfully >> - clone any version of the OpenJDK (11.09 - 16) >> - build static libraries by executing `make static-libs-image` target >> - replace `libawt.a` in GraalVM on built static library from OpenJDK >> - try to build example again and run it - it should be failed >> - clone OpenJDK with the proposed fix >> - build static libraries >> - replace `libawt.a` in GraalVM on built static library with the fix >> - build example and run it - it should be executed successfully >> >> public class AWTFixExample { >> public static void main(String[] args) { >> 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); >> >> BufferedImage image = op.filter(src, dest); >> System.out.println(image); >> } >> } >> >> [configs.zip](https://github.com/openjdk/jdk/files/5490906/configs.zip) > > I think part of the changed code is actually dead code and can be removed, I'll take a look. The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16). The changes in the mlib look fine. The testing is in progress. ------------- PR: https://git.openjdk.java.net/jdk/pull/562 From serb at openjdk.java.net Sat Nov 14 00:27:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 14 Nov 2020 00:27:55 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 Sat, 14 Nov 2020 00:23:10 GMT, Sergey Bylokhov wrote: >> I think part of the changed code is actually dead code and can be removed, I'll take a look. > > The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16). > The changes in the mlib look fine. > > The testing is in progress. please merge the master to this branch, it is quite outdated, and update the last copyright date to 2020. ------------- PR: https://git.openjdk.java.net/jdk/pull/562 From herrick at openjdk.java.net Sun Nov 15 19:09:07 2020 From: herrick at openjdk.java.net (Andy Herrick) Date: Sun, 15 Nov 2020 19:09:07 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v4] In-Reply-To: References: Message-ID: > JDK-8189198: Add "forRemoval = true" to Applet APIs Andy Herrick has updated the pull request incrementally with one additional commit since the last revision: JDK-8189198: Add "forRemoval = true" to Applet APIs ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1127/files - new: https://git.openjdk.java.net/jdk/pull/1127/files/c6ea7714..bc781bea Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1127.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127 PR: https://git.openjdk.java.net/jdk/pull/1127 From tnakamura at openjdk.java.net Mon Nov 16 13:15:14 2020 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Mon, 16 Nov 2020 13:15:14 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX Message-ID: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Hi, Could you review this fix? Under some special conditions, non-English characters were printed upside down. At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down. In this case, freetype should be prevented to use embedded bitmap. ------------- Commit messages: - 8255387: Japanese characters were printed upside down on AIX - 8255387: Japanese characters were printed upside down on AIX Changes: https://git.openjdk.java.net/jdk/pull/1218/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1218&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8255387 Stats: 120 lines in 2 files changed: 118 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1218.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1218/head:pull/1218 PR: https://git.openjdk.java.net/jdk/pull/1218 From fw at deneb.enyo.de Tue Nov 17 17:01:17 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2020 18:01:17 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> (Phil Race's message of "Mon, 2 Nov 2020 04:29:10 GMT") References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> Message-ID: <87o8jv6hpe.fsf@mid.deneb.enyo.de> * Phil Race: > This upgrades JDK to import the current 2.7.2 version of harfbuzz - > an OpenType text shaping library > > https://bugs.openjdk.java.net/browse/JDK-8247872 > > This has passed building and headless and headful automated tests on > all platforms. Is it just me, or does the new Harfbuzz build *significantly* slower? It adds about 20 seconds to the build, compared to using the system Harfbuzz, whereas before it was around 5 seconds. From philip.race at oracle.com Tue Nov 17 17:56:47 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 Nov 2020 09:56:47 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <87o8jv6hpe.fsf@mid.deneb.enyo.de> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> Message-ID: <5FB40EDF.4090300@oracle.com> There is more code in the newer version but not 4 times as much ! Harfbuzz now requires c++11 features (-std=c++11) Possibly the C++ compiler you are using (you don't mention platform) is slower in this mode. -phil. On 11/17/20, 9:01 AM, Florian Weimer wrote: > * Phil Race: > >> This upgrades JDK to import the current 2.7.2 version of harfbuzz - >> an OpenType text shaping library >> >> https://bugs.openjdk.java.net/browse/JDK-8247872 >> >> This has passed building and headless and headful automated tests on >> all platforms. > Is it just me, or does the new Harfbuzz build *significantly* slower? > > It adds about 20 seconds to the build, compared to using the system > Harfbuzz, whereas before it was around 5 seconds. From fw at deneb.enyo.de Tue Nov 17 18:00:02 2020 From: fw at deneb.enyo.de (Florian Weimer) Date: Tue, 17 Nov 2020 19:00:02 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <5FB40EDF.4090300@oracle.com> (Philip Race's message of "Tue, 17 Nov 2020 09:56:47 -0800") References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> Message-ID: <87y2iz50f1.fsf@mid.deneb.enyo.de> * Philip Race: > There is more code in the newer version but not 4 times as much ! > Harfbuzz now requires c++11 features (-std=c++11) > Possibly the C++ compiler you are using (you don't mention platform) is > slower in this mode. It's GCC 8 on Debian buster, which defaults to C++14. And it's possible to write slow-to-compile C++ in all language modes. Is the Harfbuzz build parallelized? From philip.race at oracle.com Tue Nov 17 18:08:08 2020 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 Nov 2020 10:08:08 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <87y2iz50f1.fsf@mid.deneb.enyo.de> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> <87y2iz50f1.fsf@mid.deneb.enyo.de> Message-ID: <5FB41188.30704@oracle.com> So maybe the actual *usage* of C++11 features slows it down. I found this :- https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 I really did not even think to measure the build time and I don't think there's any JDK build parallelism in building a specific native library. The build is parallel at a higher level but not at that lower level. -phil On 11/17/20, 10:00 AM, Florian Weimer wrote: > * Philip Race: > >> There is more code in the newer version but not 4 times as much ! >> Harfbuzz now requires c++11 features (-std=c++11) >> Possibly the C++ compiler you are using (you don't mention platform) is >> slower in this mode. > It's GCC 8 on Debian buster, which defaults to C++14. And it's > possible to write slow-to-compile C++ in all language modes. > > Is the Harfbuzz build parallelized? From vdyakov at openjdk.java.net Tue Nov 17 18:22:06 2020 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Tue, 17 Nov 2020 18:22:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> References: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> Message-ID: On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. @kevinrushforth @prrace could you please review? ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From vdyakov at openjdk.java.net Tue Nov 17 18:30:05 2020 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Tue, 17 Nov 2020 18:30:05 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class In-Reply-To: References: Message-ID: On Fri, 13 Nov 2020 22:50:02 GMT, Sergey Bylokhov wrote: > The implementation of ICC_Profile tries to defer loading the data of the color profile, and it uses some predefined values for some profile properties for the standard profiles like sRGB, PYCC, etc. If the application requests profile data then the ICC_Profile class activates the profile and uses properties from that data. > > Deferring mechanism for all profiles was added in JDK-6793818, but unfortunately, the color profile class was hardcoded incorrectly "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" profiles should use "CLASS_COLORSPACECONVERSION". > > Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the deferring mechanism still uses "CLASS_DISPLAY". > > As a result of this bug, the color profile reports different values before/after activations. @prsadhuk please review this fix ------------- PR: https://git.openjdk.java.net/jdk/pull/1211 From prr at openjdk.java.net Tue Nov 17 18:44:08 2020 From: prr at openjdk.java.net (Phil Race) Date: Tue, 17 Nov 2020 18:44:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> References: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> Message-ID: On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. > @kevinrushforth @prrace could you please review? As we discussed yesterday, it is reviewed but not ready to be approved. We are waiting for a reply from Apple. ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From serb at openjdk.java.net Tue Nov 17 18:59:04 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 17 Nov 2020 18:59:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU In-Reply-To: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> References: <0fKDXwkuSKcZPDRMyxmYG91a_weT0KEh7lobfkCPDY0=.e2b8fce5-4b73-47f1-b676-f8b9184a6a85@github.com> Message-ID: On Tue, 10 Nov 2020 16:38:25 GMT, Kevin Rushforth wrote: >> Change looks ok from a build point of view, but I can't comment on the validity and implications of using this key. > > I ran a 3D lighting test that is designed to be a GPU stress test. It's a worst case, to be sure, but it take 10 times as long to render with the integrated GPU as it does with the discrete GPU: > > **attenuation.LightingSample: 500 large quads** > discrete GPU: 23.5 fps > integrated GPU: 2.34 fps > > In a more realistic example of drawing a large number of 2D vectors, it runs 35% slower with the integrated GPU: > > **Vector charting test, oval clip** > discrete GPU: 41.1 fps > integrated GPU: 26.6 fps > > I see similar results in the performance numbers you listed above. > > An application developer who packages up their JDK, for example, using jpackage, can make the decision for themselves. Application developers who rely on the JDK as delivered will get whatever we choose as the default. So we need to be sure that the benefit of doing this justifies the performance hit. > > @kevinrushforth @prrace could you please review? > > As we discussed yesterday, it is reviewed but not ready to be approved. > We are waiting for a reply from Apple. @prrace We are waiting for it for three months already. If it is possible then not sure why other applications did not found any possible ways to force one specific GPU. What we are wating for? ------------- PR: https://git.openjdk.java.net/jdk/pull/1139 From magnus.ihse.bursie at oracle.com Tue Nov 17 21:40:33 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 17 Nov 2020 22:40:33 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2 In-Reply-To: <5FB41188.30704@oracle.com> References: <17xsLO4swc44fnvWNGvTiAIoAeOlQ6dHzTY_ZPQQXQ4=.0a151ce3-1533-469e-a5fd-6631ccf101cc@github.com> <87o8jv6hpe.fsf@mid.deneb.enyo.de> <5FB40EDF.4090300@oracle.com> <87y2iz50f1.fsf@mid.deneb.enyo.de> <5FB41188.30704@oracle.com> Message-ID: <608e514f-8299-46bd-6821-be17ff7aedf5@oracle.com> On 2020-11-17 19:08, Philip Race wrote: > So maybe the actual *usage* of C++11 features slows it down. > > I found this :- > https://stackoverflow.com/questions/34179434/is-compiling-with-c11-way-slower-than-with-c98 > > > I really did not even think to measure the build time and I don't > think there's any JDK build parallelism in building a specific native > library. > The build is parallel at a higher level but not at that lower level. There is build parallelism on multiple levels. When building an individual library, make is free to parallelize the compile task; only the link task is done singlethreaded. When determining which libraries to build, make is free to chose those available depending on tasks already finished. For instance, to build java.desktop-libs, we need to have finished java.desktop-java (since javac generates the header files needed by JNI integration). But after that, it can be compiled whenever make think it's suitable. This freedom for make to reorganize the order also means that it is hard to determine the additional cost for building a specific part. You could try to build java.desktop-java, and then run "make LOG=info java.desktop-libs" JOBS=1 to get a somewhat proper assessment of the time spent building all native libs for java.desktop. If this changes with the HarfBuzz upgrade, the HB upgrade is likely to blame. /Magnus > > -phil > > On 11/17/20, 10:00 AM, Florian Weimer wrote: >> * Philip Race: >> >>> There is more code in the newer version but not 4 times as much ! >>> Harfbuzz now requires c++11 features (-std=c++11) >>> Possibly the C++ compiler you are using (you don't mention platform) is >>> slower in this mode. >> It's GCC 8 on Debian buster, which defaults to C++14.? And it's >> possible to write slow-to-compile C++ in all language modes. >> >> Is the Harfbuzz build parallelized? From serb at openjdk.java.net Wed Nov 18 09:18:12 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 18 Nov 2020 09:18:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8210253: Clipped UI rendering with X11 pipeline and HiDPI Message-ID: The fix for https://bugs.openjdk.java.net/browse/JDK-8137571 where HiDPI support on Linux was implemented missed the change in the X11 pipeline, only XRender pipeline was updated. The same logic should be implemented in X11SurfaceData: - The size of the native surface should be scaled based on scale factor, except the TEXTURE type, because it is used for managed(cached) images. See the old change: https://github.com/openjdk/jdk/commit/d48c3fcafbf93177919b0e37785a340e0789789b#diff-8e84507066ac1c725caee14aa6a3323b0fb06f2082a33e0c5dbe2c662bdc53ccR545 I hit this bug on my local system, and confirm that this change cures it. mach5 is green. ------------- Commit messages: - Merge branch 'master' into JDK-8210253 - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1284/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1284&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8210253 Stats: 76 lines in 3 files changed: 41 ins; 16 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/1284.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1284/head:pull/1284 PR: https://git.openjdk.java.net/jdk/pull/1284 From philip.race at oracle.com Thu Nov 19 00:00:11 2020 From: philip.race at oracle.com (Philip Race) Date: Wed, 18 Nov 2020 16:00:11 -0800 Subject: [OpenJDK 2D-Dev] EA7 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted Message-ID: <5FB5B58B.4060000@oracle.com> The EA 7 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/ EA 7 Build 16-lanai+3-278 (2020/11/17) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 7 contains the following new bug fixes relative to EA 6 # 8256331: Lanai: DrawImage/IncorrectAlphaSurface2SW fails # 8252954: Lanai : java/awt/datatransfer/DataFlavor/DataFlavorRemoteTest.java fails # 8252951: Lanai : java/awt/Robot/NonEmptyErrorStream.java fails # 8251033: Background texture is not visible when Alpha Composite is enabled # 8238533: [Lanai] Support texture paint where source is transparent # 8248129: Swingmark numbers are not good for Nimbus LAF # 8255212: J2DDemo : Rectangle in Texture paint disappears if we enable AA # 8255149: Lanai: DrawImage/IncorrectAlphaConversionBicubic.java failure # 8244718: J2DDemo - AlphaComposite tab - output colors are different with AA & non-AA # 8254881: Commit commandbuffer after draw happens through JNI # 8254879: Implement JNI path for Draw Poly # 8254869: Refactor check_previous_op usage in Mask Fill # 8244845: Lanai : J2DDemo - Clipping - Two parallel lines do not appear with AA Rendering # 8242924: Selection is not correct in Paint.TextureAnim # 8253994: J2DDemo: Buttcap, SquareCap color is different in AlphaComposite mode # 8252726: Lanai: IDEA Editor Rendering OGL vs Metal 1:2 # 8254176: Lanai: MTLTexturePool optimize lookup of expired textures -phil. [1] https://wiki.openjdk.java.net/display/lanai/Main -------------- next part -------------- An HTML attachment was scrubbed... URL: From psadhukhan at openjdk.java.net Thu Nov 19 11:01:06 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 19 Nov 2020 11:01:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class In-Reply-To: References: Message-ID: On Tue, 17 Nov 2020 18:27:06 GMT, Victor Dyakov wrote: >> The implementation of ICC_Profile tries to defer loading the data of the color profile, and it uses some predefined values for some profile properties for the standard profiles like sRGB, PYCC, etc. If the application requests profile data then the ICC_Profile class activates the profile and uses properties from that data. >> >> Deferring mechanism for all profiles was added in JDK-6793818, but unfortunately, the color profile class was hardcoded incorrectly "CLASS_DISPLAY" for all profiles. However, the "CIEXYZ.pf" and "PYCC.pf" profiles should use "CLASS_COLORSPACECONVERSION". >> >> Later the color "profiles/xxx.pf" were replaced in the JDK, and the actual type of the "CIEXYZ.pf" was changed to the "CLASS_ABSTRACT", but the deferring mechanism still uses "CLASS_DISPLAY". >> >> As a result of this bug, the color profile reports different values before/after activations. > > @prsadhuk please review this fix It will be good to know where, in spec or any link, it is mentioned to use CLASS_ABSTRACT/CLASS_COLORSPACECONVERSION instead of CLASS_DISPLAY? ------------- PR: https://git.openjdk.java.net/jdk/pull/1211 From serb at openjdk.java.net Thu Nov 19 16:54:12 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 19 Nov 2020 16:54:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class In-Reply-To: References: Message-ID: <6T3xY7dSaz4icSbshoDqViGni-v4UqPFylDGB7P8tBw=.f052d5b3-349e-474e-8dd7-d52695bf217d@github.com> On Thu, 19 Nov 2020 10:58:01 GMT, Prasanta Sadhukhan wrote: > It will be good to know where, in spec or any link, it is mentioned to use CLASS_ABSTRACT/CLASS_COLORSPACECONVERSION instead of CLASS_DISPLAY? It is not specified, it is reflected the data used by our current icc profiles "CIEXYZ.pf" and "PYCC.pf" from the: open/src/java.desktop/share/classes/sun/java2d/cmm/profiles/ ------------- PR: https://git.openjdk.java.net/jdk/pull/1211 From serb at openjdk.java.net Fri Nov 20 00:47:03 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 20 Nov 2020 00:47:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX In-Reply-To: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Message-ID: On Mon, 16 Nov 2020 09:09:50 GMT, Toshio Nakamura wrote: > Hi, > > Could you review this fix? Under some special conditions, non-English characters were printed upside down. > > At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down. > > In this case, freetype should be prevented to use embedded bitmap. test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 40: > 38: import java.awt.image.BufferedImage; > 39: > 40: public class PrintTranslateTest{ Does it really bind to the printing/"print/PrinterJob", look like the bug is reproduced in the common rendering as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/1218 From serb at openjdk.java.net Fri Nov 20 06:14:08 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 20 Nov 2020 06:14:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8198390: Test MultiResolutionDrawImageWithTransformTest.java fails when -esa is passed Message-ID: <05wVpL45xSJCiozMme1S6VAjXTAmyWiLpM6aAhNZgzw=.928403c2-d279-41c1-9d7f-6d9e14cbc46b@github.com> The method in which the assertion fails called from the different places, sometimes bounds are passed(dx/dy) and the transform only once here: https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3571 For the case when the transform is passed we have an assertion that checks some assumptions about the(dx/dy): - The dx1/dy1 should be equal to 0, which means both values are not changed by the method. - The dx2/dy2 should be equal to the image size(MRI) -> are not changed by the method as well. The second assertion is wrong. The dx2/dy2 passed to the method contains the size of the initial image(MRI), and an assertion checks it against the size of the "resolution variant" which may have a different DPI/resolution/size. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8198390 Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/1333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1333/head:pull/1333 PR: https://git.openjdk.java.net/jdk/pull/1333 From serb at openjdk.java.net Fri Nov 20 06:34:03 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 20 Nov 2020 06:34:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows In-Reply-To: References: Message-ID: On Thu, 12 Nov 2020 10:32:16 GMT, Alexander Scherbatiy wrote: > Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path coordinates. > Rounding GlyphVector outline coordinates leads to distorted printed text. > > To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI > printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by > filling GlyphVector outline. Chars on the second line are distorted. > > It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) > > The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled > scales the GDI WorldTransform down and GlyphVector outline coordinates up. > This allows to keep some digits after a dot from being rounded. > The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: > https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 > > See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. > > [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. I am not sure that we need the additional property for things other than possibly to workaround some possible bugs. I am fine if we will use the scaled version all the time, does it have any drawbacks? ------------- PR: https://git.openjdk.java.net/jdk/pull/1183 From tnakamura at openjdk.java.net Fri Nov 20 08:37:24 2020 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Fri, 20 Nov 2020 08:37:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX [v2] In-Reply-To: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Message-ID: > Hi, > > Could you review this fix? Under some special conditions, non-English characters were printed upside down. > > At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down. > > In this case, freetype should be prevented to use embedded bitmap. Toshio Nakamura has updated the pull request incrementally with two additional commits since the last revision: - fix space - Changed test location and name ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1218/files - new: https://git.openjdk.java.net/jdk/pull/1218/files/a5b3e9c5..97082032 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1218&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1218&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/1218.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1218/head:pull/1218 PR: https://git.openjdk.java.net/jdk/pull/1218 From tnakamura at openjdk.java.net Fri Nov 20 08:46:04 2020 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Fri, 20 Nov 2020 08:46:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX [v2] In-Reply-To: References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Message-ID: On Fri, 20 Nov 2020 00:44:40 GMT, Sergey Bylokhov wrote: >> Toshio Nakamura has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix space >> - Changed test location and name > > test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 40: > >> 38: import java.awt.image.BufferedImage; >> 39: >> 40: public class PrintTranslateTest{ > > Does it really bind to the printing/"print/PrinterJob", look like the bug is reproduced in the common rendering as well? Thank you Sergey for your advice. I moved the test case under test/jdk/java/awt/font and changed the name. The original problem is at printing, but yes it's common rendering. ------------- PR: https://git.openjdk.java.net/jdk/pull/1218 From alexsch at openjdk.java.net Fri Nov 20 20:05:21 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 20 Nov 2020 20:05:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows [v2] In-Reply-To: References: Message-ID: > Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path coordinates. > Rounding GlyphVector outline coordinates leads to distorted printed text. > > To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI > printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by > filling GlyphVector outline. Chars on the second line are distorted. > > It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) > > The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled > scales the GDI WorldTransform down and GlyphVector outline coordinates up. > This allows to keep some digits after a dot from being rounded. > The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: > https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 > > See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. > > [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Remove sun.java2d.print.enablePathPrecisionScale property from JDK-8256264 fix ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1183/files - new: https://git.openjdk.java.net/jdk/pull/1183/files/120ae32b..f79b8014 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1183&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1183&range=00-01 Stats: 18 lines in 1 file changed: 0 ins; 10 del; 8 mod Patch: https://git.openjdk.java.net/jdk/pull/1183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1183/head:pull/1183 PR: https://git.openjdk.java.net/jdk/pull/1183 From alexsch at openjdk.java.net Fri Nov 20 20:26:10 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 20 Nov 2020 20:26:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 06:31:24 GMT, Sergey Bylokhov wrote: >> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. >> The GDI system used for text printing on Windows accepts only integer path coordinates. >> Rounding GlyphVector outline coordinates leads to distorted printed text. >> >> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI >> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by >> filling GlyphVector outline. Chars on the second line are distorted. >> >> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) >> >> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled >> scales the GDI WorldTransform down and GlyphVector outline coordinates up. >> This allows to keep some digits after a dot from being rounded. >> The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: >> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 >> >> See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. >> >> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. > > I am not sure that we need the additional property for things other than possibly to workaround some possible bugs. I am fine if we will use the scaled version all the time, does it have any drawbacks? I prepared a simple [print test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) sample which uses 4 different fonts (plain and bold) with different sizes and prints 640 lines on 10 pages. I run the sample with and without the fix to PDF and measured the time which is used by the deviceFill() method (it both converts the shape to path and fills it): https://github.com/openjdk/jdk/blob/b21b96df2162c72098afcdfd2cf243a55a0f17e1/src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java#L1489 The average time without the fix: 2.77s (min 2.74s, max 2,78) The average time with the fix: 2.76s (min 2.74s, max 2.77) I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/1183 From serb at openjdk.java.net Sun Nov 22 08:15:31 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 22 Nov 2020 08:15:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails Message-ID: These tests draw some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels. The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%). The solution is to use some predefined scale to pass the tests, to reproduce initial bug scale=1 is enough. One test fails because of the bug in the XRender pipeline. ------------- Commit messages: - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1372/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1372&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196086 Stats: 18 lines in 5 files changed: 11 ins; 3 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1372.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1372/head:pull/1372 PR: https://git.openjdk.java.net/jdk/pull/1372 From shade at openjdk.java.net Mon Nov 23 09:50:58 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Mon, 23 Nov 2020 09:50:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 07:36:12 GMT, Sergey Bylokhov wrote: > These tests draw some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels. > > The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%). > > The solution is to use some predefined scale to pass the tests, to reproduce initial bug scale=1 is enough. > One test fails because of the bug in the XRender pipeline. I have a drive-by question: why do some tests run with `-Dsun.java2d.uiScale=3`, and some are not? ------------- PR: https://git.openjdk.java.net/jdk/pull/1372 From psadhukhan at openjdk.java.net Mon Nov 23 10:48:57 2020 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Mon, 23 Nov 2020 10:48:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class In-Reply-To: <6T3xY7dSaz4icSbshoDqViGni-v4UqPFylDGB7P8tBw=.f052d5b3-349e-474e-8dd7-d52695bf217d@github.com> References: <6T3xY7dSaz4icSbshoDqViGni-v4UqPFylDGB7P8tBw=.f052d5b3-349e-474e-8dd7-d52695bf217d@github.com> Message-ID: On Thu, 19 Nov 2020 16:51:00 GMT, Sergey Bylokhov wrote: >> It will be good to know where, in spec or any link, it is mentioned to use CLASS_ABSTRACT/CLASS_COLORSPACECONVERSION instead of CLASS_DISPLAY? > >> It will be good to know where, in spec or any link, it is mentioned to use CLASS_ABSTRACT/CLASS_COLORSPACECONVERSION instead of CLASS_DISPLAY? > > It is not specified, it is reflected the data used by our current icc profiles "CIEXYZ.pf" and "PYCC.pf" from the: > open/src/java.desktop/share/classes/sun/java2d/cmm/profiles/ I am not sure how to interpret this .pf file as this are binary file. Probably whoever generated this pf file can comment on this modification. ------------- PR: https://git.openjdk.java.net/jdk/pull/1211 From serb at openjdk.java.net Tue Nov 24 01:37:56 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 24 Nov 2020 01:37:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails In-Reply-To: References: Message-ID: On Mon, 23 Nov 2020 09:48:07 GMT, Aleksey Shipilev wrote: > I have a drive-by question: why do some tests run with `-Dsun.java2d.uiScale=3`, and some are not? The tests which use odd scale=3 are more tolerant to the artifacts caused by the interpolation when a bigger image is drawn to the smaller image. ------------- PR: https://git.openjdk.java.net/jdk/pull/1372 From serb at openjdk.java.net Wed Nov 25 00:52:09 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 25 Nov 2020 00:52:09 GMT Subject: [OpenJDK 2D-Dev] RFR: 8196100: javax/swing/text/JTextComponent/5074573/bug5074573.java fails Message-ID: Here is a fix for one of the annoying bug, which causes random test failures in the CI. We have a method Robot.waitForIdle(), which supposed to wait until the java and the native queue stabilized. The common use case is to click on the button or show the window, and call waitForIdle() which will wait until the native event will be dispatched by the X11/Windows/macOS as well as followed Java event(paint/focus/etc event) will be dispatched to the EDT. Currently, it is implemented in this way: 1. Flush the EventQueue, so all old events will be posted to EDT. 2. Flush the native event queue, by posting the native event. 3. Flush the EDT, by posting a java event. 4. If some events(unrelated to waitForIdle machinery) were dispatched on steps 2. or 3. then repeat since step 1. It is implemented that they because the native events caused by the OS usually generate the java events, and the java events may generate native events. So we have to wait for both queues (java/native). But it has the next disadvantages: - It is implemented as a busy loop, which does not give a chance for the application to proceed further since it blocks 3 threads EDT/native toolkit thread like appkit/main thread. - It throws the InfiniteLoop exception if the number of attempts is bigger than 20. And this limitation is too small because some tests generate much more events during startup. - Note that the timeout value for the realSync method is 10 seconds, and it was assumed that this method will not be executed longer, but it uses this timeout for all events flushing which can lead up to 600 seconds (20 iters * 3 calls * 10 seconds). The fix: - Add a small delay to the method, so the app can do something useful when waitForIdle() is called - The timeout=10 second is taken care of, we calculate the "end" time and exits if it is exceeded - The maximum number of attempts is increased to 100 and InfiniteLoop is removed. Note that I have made one additional change to the new realSync implementation. At the beginning of the method I call: EventQueue.invokeAndWait(() -> {/*dummy implementation*/}); It is needed to be sure that we flush the first event on EDT even if we spend more time than 10 seconds. ------------- Commit messages: - Update SunToolkit.java - The new tests - Do not use shared state - Update SunToolkit.java - realSync too slow - Update bug5074573.java - Test update - Initial fix Changes: https://git.openjdk.java.net/jdk/pull/1424/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1424&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8196100 Stats: 242 lines in 9 files changed: 192 ins; 20 del; 30 mod Patch: https://git.openjdk.java.net/jdk/pull/1424.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1424/head:pull/1424 PR: https://git.openjdk.java.net/jdk/pull/1424 From shade at openjdk.java.net Thu Nov 26 10:19:55 2020 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 26 Nov 2020 10:19:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 07:36:12 GMT, Sergey Bylokhov wrote: > These tests draw some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels. > > The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%). > > The solution is to use some predefined scale to pass the tests, to reproduce initial bug scale=1 is enough. > One test fails because of the bug in the XRender pipeline. Thanks for the explanation. Looks fine to me then. ------------- Marked as reviewed by shade (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1372 From serb at openjdk.java.net Sat Nov 28 04:33:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 28 Nov 2020 04:33:55 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails In-Reply-To: References: Message-ID: On Sun, 22 Nov 2020 07:36:12 GMT, Sergey Bylokhov wrote: > These tests draw some specific pattern to the VolatileImage and to the BufferedImage, and then compare pixels. > > The test uses the getSnapshot() method to get the pixels from VolatileImage, and this method produces some interpolation "artifacts" if the fractional scale is used in the system(like 125%). > > The solution is to use some predefined scale to pass the tests, to reproduce initial bug scale=1 is enough. > One test fails because of the bug in the XRender pipeline. This pull request has now been integrated. Changeset: 1241f800 Author: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/1241f800 Stats: 18 lines in 5 files changed: 11 ins; 3 del; 4 mod 8196086: java/awt/image/DrawImage/IncorrectSourceOffset.java fails Reviewed-by: shade ------------- PR: https://git.openjdk.java.net/jdk/pull/1372 From serb at openjdk.java.net Sat Nov 28 20:09:54 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 28 Nov 2020 20:09:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows In-Reply-To: References: Message-ID: On Fri, 20 Nov 2020 20:23:23 GMT, Alexander Scherbatiy wrote: > I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix. You forgot to delete it from the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1183 From serb at openjdk.java.net Mon Nov 30 03:44:58 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Nov 2020 03:44:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8210253: Clipped UI rendering with X11 pipeline and HiDPI In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 09:11:11 GMT, Sergey Bylokhov wrote: > The fix for https://bugs.openjdk.java.net/browse/JDK-8137571 where HiDPI support on Linux was implemented missed the change in the X11 pipeline, only XRender pipeline was updated. The same logic should be implemented in X11SurfaceData: > > - The size of the native surface should be scaled based on scale factor, except the TEXTURE type, because it is used for managed(cached) images. > > See the old change: > https://github.com/openjdk/jdk/commit/d48c3fcafbf93177919b0e37785a340e0789789b#diff-8e84507066ac1c725caee14aa6a3323b0fb06f2082a33e0c5dbe2c662bdc53ccR545 > > I hit this bug on my local system, and confirm that this change cures it. mach5 is green. Any volunteers for a review? ------------- PR: https://git.openjdk.java.net/jdk/pull/1284 From serb at openjdk.java.net Mon Nov 30 03:45:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Nov 2020 03:45:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8198390: Test MultiResolutionDrawImageWithTransformTest.java fails when -esa is passed In-Reply-To: <05wVpL45xSJCiozMme1S6VAjXTAmyWiLpM6aAhNZgzw=.928403c2-d279-41c1-9d7f-6d9e14cbc46b@github.com> References: <05wVpL45xSJCiozMme1S6VAjXTAmyWiLpM6aAhNZgzw=.928403c2-d279-41c1-9d7f-6d9e14cbc46b@github.com> Message-ID: On Fri, 20 Nov 2020 00:10:48 GMT, Sergey Bylokhov wrote: > The method in which the assertion fails called from the different places, sometimes bounds are passed(dx/dy) and the transform only once here: > https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3571 > > For the case when the transform is passed we have an assertion that checks some assumptions about the(dx/dy): > - The dx1/dy1 should be equal to 0, which means both values are not changed by the method. > - The dx2/dy2 should be equal to the image size(MRI) -> are not changed by the method as well. > > The second assertion is wrong. The dx2/dy2 passed to the method contains the size of the initial image(MRI), and an assertion checks it against the size of the "resolution variant" which may have a different DPI/resolution/size. Any volunteers for a review? ------------- PR: https://git.openjdk.java.net/jdk/pull/1333 From serb at openjdk.java.net Mon Nov 30 03:45:55 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Nov 2020 03:45:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256321: Some "inactive" color profiles use the wrong profile class In-Reply-To: References: <6T3xY7dSaz4icSbshoDqViGni-v4UqPFylDGB7P8tBw=.f052d5b3-349e-474e-8dd7-d52695bf217d@github.com> Message-ID: On Mon, 23 Nov 2020 10:46:03 GMT, Prasanta Sadhukhan wrote: >>> It will be good to know where, in spec or any link, it is mentioned to use CLASS_ABSTRACT/CLASS_COLORSPACECONVERSION instead of CLASS_DISPLAY? >> >> It is not specified, it is reflected the data used by our current icc profiles "CIEXYZ.pf" and "PYCC.pf" from the: >> open/src/java.desktop/share/classes/sun/java2d/cmm/profiles/ > > I am not sure how to interpret this .pf file as this are binary file. Probably whoever generated this pf file can comment on this modification. @prrace please take a look ------------- PR: https://git.openjdk.java.net/jdk/pull/1211 From alexsch at openjdk.java.net Mon Nov 30 10:00:17 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 30 Nov 2020 10:00:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows [v3] In-Reply-To: References: Message-ID: > Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. > The GDI system used for text printing on Windows accepts only integer path coordinates. > Rounding GlyphVector outline coordinates leads to distorted printed text. > > To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI > printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by > filling GlyphVector outline. Chars on the second line are distorted. > > It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) > > The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled > scales the GDI WorldTransform down and GlyphVector outline coordinates up. > This allows to keep some digits after a dot from being rounded. > The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: > https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 > > See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. > > [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Remove Dsun.java2d.print.enablePathPrecisionScale property from the PathPrecisionScaleFactorTest ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/1183/files - new: https://git.openjdk.java.net/jdk/pull/1183/files/f79b8014..b6885e5f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1183&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1183&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1183.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1183/head:pull/1183 PR: https://git.openjdk.java.net/jdk/pull/1183 From alexsch at openjdk.java.net Mon Nov 30 10:00:18 2020 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 30 Nov 2020 10:00:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows In-Reply-To: References: Message-ID: On Sat, 28 Nov 2020 20:07:22 GMT, Sergey Bylokhov wrote: >> I prepared a simple [print test](http://cr.openjdk.java.net/~alexsch/8256264/performance/PrintTextPerformanceTest.java) sample which uses 4 different fonts (plain and bold) with different sizes and prints 640 lines on 10 pages. >> >> I run the sample with and without the fix to PDF and measured the time which is used by the deviceFill() method (it both converts the shape to path and fills it): >> https://github.com/openjdk/jdk/blob/b21b96df2162c72098afcdfd2cf243a55a0f17e1/src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java#L1489 >> >> The average time without the fix: 2.77s (min 2.74s, max 2,78) >> The average time with the fix: 2.76s (min 2.74s, max 2.77) >> >> I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix. > >> I removed the `sun.java2d.print.enablePathPrecisionScale` property from the fix. > > You forgot to delete it from the test. The `sun.java2d.print.enablePathPrecisionScale` property is removed from the PathPrecisionScaleFactorTest test. ------------- PR: https://git.openjdk.java.net/jdk/pull/1183 From serb at openjdk.java.net Mon Nov 30 17:21:58 2020 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Mon, 30 Nov 2020 17:21:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8256264: Printed GlyphVector outline with low DPI has bad quality on Windows [v3] In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 10:00:17 GMT, Alexander Scherbatiy wrote: >> Printing text using GlyphVector outline has bad quality on printers with low DPI on Windows. >> The GDI system used for text printing on Windows accepts only integer path coordinates. >> Rounding GlyphVector outline coordinates leads to distorted printed text. >> >> To reproduce the issue run the [PrintGlyphVectorOutlineSample](https://bugs.openjdk.java.net/secure/attachment/91398/PrintGlyphVectorOutlineSample.java) file on Windows and select a low DPI >> printer in the printer dialog. The sample prints two lines, one using Graphics drawString() method and another by >> filling GlyphVector outline. Chars on the second line are distorted. >> >> It is also possible to reproduce the issue running the sample and printing the text to PDF: [fill-glyph-vector-outline.png](https://bugs.openjdk.java.net/secure/attachment/91397/fill-glyph-vector-outline.png) >> >> The proposed fix introduce "sun.java2d.print.enablePathPrecisionScale" property which being enabled >> scales the GDI WorldTransform down and GlyphVector outline coordinates up. >> This allows to keep some digits after a dot from being rounded. >> The value for scaling is chosen to be 1000 in the same way how it is used by `String trunc(float f)` method from PSPrinterJob class on Linux: >> https://github.com/openjdk/jdk/blob/ed615e3ca0d681e8e67cdbf1d5d964979ccd7888/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1489 >> >> See the [fill-glyph-vector-outline-enable-path-scale-factor.png](https://bugs.openjdk.java.net/secure/attachment/91399/fill-glyph-vector-outline-enable-path-scale-factor.png) screenshot which shows how the GlyphVector outline is filled after the fix with the enabled "sun.java2d.print.enablePathPrecisionScale" option. >> >> [fill-glyph-vector-outline-diff.png](https://bugs.openjdk.java.net/secure/attachment/91400/fill-glyph-vector-outline-diff.png) shows difference of GlyphVector outline printing before and after the fix. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Remove Dsun.java2d.print.enablePathPrecisionScale property from the PathPrecisionScaleFactorTest Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/1183 From github.com+1538227+arodionov at openjdk.java.net Mon Nov 30 17:53:26 2020 From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov) Date: Mon, 30 Nov 2020 17:53:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and Swing to work with GraalVM Native Image [v3] 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 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 one additional 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/65d3e835..47252ec8 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=562&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=562&range=01-02 Stats: 644800 lines in 4146 files changed: 524091 ins; 79120 del; 41589 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 Mon Nov 30 22:32:00 2020 From: github.com+1538227+arodionov at openjdk.java.net (Andrii Rodionov) Date: Mon, 30 Nov 2020 22:32:00 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 Sat, 14 Nov 2020 00:25:21 GMT, Sergey Bylokhov wrote: >> The changes in awt_LoadLibrary.c and XToolkit.c is mostly noop except excluding dladdr/dlopen. Since XsessionWMcommand/AWTIsHeadless are not used at least in the mainline(jdk16). >> The changes in the mlib look fine. >> >> The testing is in progress. > > please merge the master to this branch, it is quite outdated, and update the last copyright date to 2020. @mrserb I have rebased PR on the master, but `XsessionWMcommand` and `AWTIsHeadless` functions are still at `XToolkit.c` in the mainline. So, to prevent the conflicting symbols error during static libraries linkage (`libawt.a` and `libawt_xawt.a`), we need to rename or to hide conflicting functions. ------------- PR: https://git.openjdk.java.net/jdk/pull/562 From vdyakov at openjdk.java.net Mon Nov 30 22:33:10 2020 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Mon, 30 Nov 2020 22:33:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8210253: Clipped UI rendering with X11 pipeline and HiDPI In-Reply-To: References: Message-ID: On Mon, 30 Nov 2020 03:42:24 GMT, Sergey Bylokhov wrote: >> The fix for https://bugs.openjdk.java.net/browse/JDK-8137571 where HiDPI support on Linux was implemented missed the change in the X11 pipeline, only XRender pipeline was updated. The same logic should be implemented in X11SurfaceData: >> >> - The size of the native surface should be scaled based on scale factor, except the TEXTURE type, because it is used for managed(cached) images. >> >> See the old change: >> https://github.com/openjdk/jdk/commit/d48c3fcafbf93177919b0e37785a340e0789789b#diff-8e84507066ac1c725caee14aa6a3323b0fb06f2082a33e0c5dbe2c662bdc53ccR545 >> >> I hit this bug on my local system, and confirm that this change cures it. mach5 is green. > > Any volunteers for a review? @prsadhuk @kizune please review ------------- PR: https://git.openjdk.java.net/jdk/pull/1284 From vdyakov at openjdk.java.net Mon Nov 30 22:40:01 2020 From: vdyakov at openjdk.java.net (Victor Dyakov) Date: Mon, 30 Nov 2020 22:40:01 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX In-Reply-To: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Message-ID: On Mon, 16 Nov 2020 09:09:50 GMT, Toshio Nakamura wrote: > Hi, > > Could you review this fix? Under some special conditions, non-English characters were printed upside down. > > At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down. > > In this case, freetype should be prevented to use embedded bitmap. @mrserb @prrace please review ------------- PR: https://git.openjdk.java.net/jdk/pull/1218 From aivanov at openjdk.java.net Mon Nov 30 23:13:56 2020 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Mon, 30 Nov 2020 23:13:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8210253: Clipped UI rendering with X11 pipeline and HiDPI In-Reply-To: References: Message-ID: On Wed, 18 Nov 2020 09:11:11 GMT, Sergey Bylokhov wrote: > The fix for https://bugs.openjdk.java.net/browse/JDK-8137571 where HiDPI support on Linux was implemented missed the change in the X11 pipeline, only XRender pipeline was updated. The same logic should be implemented in X11SurfaceData: > > - The size of the native surface should be scaled based on scale factor, except the TEXTURE type, because it is used for managed(cached) images. > > See the old change: > https://github.com/openjdk/jdk/commit/d48c3fcafbf93177919b0e37785a340e0789789b#diff-8e84507066ac1c725caee14aa6a3323b0fb06f2082a33e0c5dbe2c662bdc53ccR545 > > I hit this bug on my local system, and confirm that this change cures it. mach5 is green. The changes are similar to Xrender, looks reasonable. ------------- Marked as reviewed by aivanov (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1284 From prr at openjdk.java.net Mon Nov 30 23:30:02 2020 From: prr at openjdk.java.net (Phil Race) Date: Mon, 30 Nov 2020 23:30:02 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX [v2] In-Reply-To: References: <-zl1EqjwYppCrp7Wdifz42Jagial2KqVXkEbAxMciUc=.5b75c16d-f0e8-427f-b3b4-62aca0076732@github.com> Message-ID: On Fri, 20 Nov 2020 08:37:24 GMT, Toshio Nakamura wrote: >> Hi, >> >> Could you review this fix? Under some special conditions, non-English characters were printed upside down. >> >> At printing with raster image, the image was generated from bottom to top. So, each characters should also be drawn as vertical mirrored. However, freetype doesn't support to transform it if the font is using embedded bitmap and non-English. As the result, these Japanese characters were printed as upside down. >> >> In this case, freetype should be prevented to use embedded bitmap. > > Toshio Nakamura has updated the pull request incrementally with two additional commits since the last revision: > > - fix space > - Changed test location and name Changes requested by prr (Reviewer). test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 27: > 25: * @test PrintTranslateTest > 26: * @bug 8255387 > 27: * @summary Vertial mirrored characters should be drawn correctly Vertial -> Vertical test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 41: > 39: > 40: public class PrintTranslateTest{ > 41: static String target = "\u3042"; Add a space before { test/jdk/java/awt/print/PrinterJob/PrintTranslateTest.java line 47: > 45: static BufferedImage drawNormal(Font font) { > 46: BufferedImage image = new BufferedImage(SIZE, SIZE, > 47: BufferedImage.TYPE_BYTE_BINARY); I suppose you chose BYTE_BINARY so that AA glyphs have to rendered as mono making the comparison easier ? src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 533: > 531: !context->doBold && !context->doItalize && > 532: (context->transform.yx == 0) && (context->transform.xy == 0) && > 533: (context->transform.yy > 0)) So what about xx ? Mirroring horizontally ? ------------- PR: https://git.openjdk.java.net/jdk/pull/1218