Re: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX [v4]
On Mon, 7 Dec 2020 07:32:30 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 one > additional commit since the last revision: > > Revise the test to compare center of gravity An updated test works fine. - Marked as reviewed by serb (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1218
Re: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX
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. @toshiona you can push it as you have 2 approvals. As a reminder today is a last day for fixing P4s in jdk 16 - PR: https://git.openjdk.java.net/jdk/pull/1218
Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU
On Tue, 17 Nov 2020 18:55:51 GMT, Sergey Bylokhov wrote: >> 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? @mrserb @prrace what is a back up plan in case we will not have a reply from Apple? (as we do not have it for 4! months). Definitely we need a plan B - PR: https://git.openjdk.java.net/jdk/pull/1139
[OpenJDK 2D-Dev] RFR: 8256888: Client manual test problem list update
Update the problem list. - Commit messages: - 8256888: Client manual test problem list update Changes: https://git.openjdk.java.net/jdk/pull/1396/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8256888 Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/1396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1396/head:pull/1396 PR: https://git.openjdk.java.net/jdk/pull/1396
Re: [OpenJDK 2D-Dev] RFR: 8254024: Enhance native libs for AWT and Swing to work with GraalVM Native Image
On Wed, 9 Dec 2020 01:26:08 GMT, Phil Race wrote: >> No, we produce only one image. The headless/non-headless mode is defined by >> the system property `-Djava.awt.headless=...`. >> Here is a command example for native image generation: >> `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image >> -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true >> AWTFixExample` >> >> With `-Djava.awt.headless=false` to the gcc linker we pass `libawt.a` and >> `libawt_headless.a` >> With `-Djava.awt.headless=true` to the gcc linker we pass `libawt.a` and >> `libawt-xawt.a` >> If the generated image demands `libmlib_image.a` it will be also linked. > >> No, we produce only one image. The headless/non-headless mode is defined by >> the system property `-Djava.awt.headless=...`. >> Here is a command example for native image generation: >> `$ ~/graalvm-ce-java11-21.0.0-dev/bin/native-image >> -H:ConfigurationFileDirectories=./configs -Djava.awt.headless=true >> AWTFixExample` >> >> With `-Djava.awt.headless=false` to the gcc linker we pass `libawt.a` and >> `libawt_headless.a` >> With `-Djava.awt.headless=true` to the gcc linker we pass `libawt.a` and >> `libawt-xawt.a` >> If the generated image demands `libmlib_image.a` it will be also linked. > > -Djava.awt.headless is a runtime property not a build time property. So you > are doing domething very weird. > How does that image with "false" run a UI app ? It can't. And yet the one > with "true" still can run without an xserver, except it will not start unless > you have X11 libs installed - and I am *reasonably* sure you aren't > statically linking all the system provided libraries ... I hope ... > > So how does a "user" use all of this ? Seems they must create their own app > by native compile + linking. > Can they create an image that can run any java app, or must the app like > AWTFixExample be linked in to the image ? At the current stage, we made the `-Djava.awt.headless` option be used during the build time, at the same time it does no influence at the runtime. The user should know the environment where it is planned to run a native image in advance. It is his responsibility to pass correct options to the native image compiler. For example, for the code snippet `AWTFixExample` (mentioned above https://github.com/openjdk/jdk/pull/562#issuecomment-722023476), that is headless, the following set of static libraries are used for image build: # Static libraries: # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/svm/clibraries/linux-amd64/liblibchelper.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/liblcms.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libawt_headless.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libawt.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libmlib_image.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libnet.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libnio.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libjava.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libfdlibm.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libzip.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/svm/clibraries/linux-amd64/libjvm.a # Other libraries: stdc++,m,pthread,dl,z,rt For simple AWT UI Java app, the set of libraries are the following: # Static libraries: # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libnet.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libjavajpeg.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libnio.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/svm/clibraries/linux-amd64/liblibchelper.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libjava.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/liblcms.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libfontmanager.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libawt_xawt.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libawt.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libfdlibm.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/static/linux-amd64/glibc/libzip.a # ../../vms/graalvm-ce-java11-21.0.0-dev/lib/svm/clibraries/linux-amd64/libjvm.a # Other libraries: X11,Xrender,Xext,Xi,stdc++,m,freetype,pthread,dl,z,rt > So how does a "user" use all of this ? Seems they must create their own app > by native compile + linking. > Can they create an image that can run any java app, or must the app like > AWTFixExample be linked in to the image ? The global idea is that any existing Java app (even without source code) can be converted into a native image, that's why we have added A
Re: [OpenJDK 2D-Dev] RFR: 8256888: Client manual test problem list update
On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race wrote: > Update the problem list. test/jdk/ProblemList.txt line 877: > 875: javax/swing/JTabbedPane/4666224/bug4666224.html 8144124 macosx-all > 876: java/awt/event/MouseEvent/AltGraphModifierTest/AltGraphModifierTest.java > 8162380 generic-all > 877: java/awt/Window/TranslucentJAppletTest/TranslucentJAppletTest.java > 8163086 macosx-all,linux-all The failure of this test on Linux was reported on 02.2019 last time. Since then only the problem on macOS is reported. Does the test actually fail on Linux right now? test/jdk/ProblemList.txt line 889: > 887: javax/swing/JTabbedPane/4209065/bug4209065.java 8251177 macosx-all > 888: java/awt/TrayIcon/DragEventSource/DragEventSource.java 8252242 macosx-all > 889: java/awt/FileDialog/DefaultFocusOwner/DefaultFocusOwner.java 7187728 > macosx-all,linux-all,solaris-all Al usage of Solaris-xxx in the problem list was removed by the https://github.com/openjdk/jdk/commit/071bd521bca2485c6df95c45e4310d39b05bd046#diff-80063aaf72a19fa27f001c17fc7687086ea71b35b01f5e2b3fcd7f50d8c682fbL252 - PR: https://git.openjdk.java.net/jdk/pull/1396
Re: [OpenJDK 2D-Dev] RFR: 8255387: Japanese characters were printed upside down on AIX [v4]
On Wed, 9 Dec 2020 09:16:41 GMT, Sergey Bylokhov wrote: >> Toshio Nakamura has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Revise the test to compare center of gravity > > An updated test works fine. @mrserb @prrace Thank you so much for the review. Could you sponsor this patch? - PR: https://git.openjdk.java.net/jdk/pull/1218
[OpenJDK 2D-Dev] Integrated: 8255387: Japanese characters were printed upside down on AIX
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. This pull request has now been integrated. Changeset: 53e537c7 Author:Toshio Nakamura Committer: Phil Race URL: https://git.openjdk.java.net/jdk/commit/53e537c7 Stats: 166 lines in 2 files changed: 164 ins; 0 del; 2 mod 8255387: Japanese characters were printed upside down on AIX Reviewed-by: prr, serb - PR: https://git.openjdk.java.net/jdk/pull/1218
Re: [OpenJDK 2D-Dev] RFR: 8256888: Client manual test problem list update [v2]
> Update the problem list. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8256888: Client manual test problem list update - Changes: - all: https://git.openjdk.java.net/jdk/pull/1396/files - new: https://git.openjdk.java.net/jdk/pull/1396/files/df1507d9..767990eb Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1396&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/1396.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/1396/head:pull/1396 PR: https://git.openjdk.java.net/jdk/pull/1396
Re: [OpenJDK 2D-Dev] RFR: 8256888: Client manual test problem list update
On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race wrote: > Update the problem list. I've removed the references to Solaris and the reference to Linux that was not needed. - PR: https://git.openjdk.java.net/jdk/pull/1396
Re: [OpenJDK 2D-Dev] RFR: 8257733: Move module-specific data from make to respective module [v2]
On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie wrote: >> A lot (but not all) of the data in make/data is tied to a specific module. >> For instance, the publicsuffixlist is used by java.base, and fontconfig by >> java.desktop. (A few directories, like mainmanifest, is *actually* used by >> make for the whole build.) >> >> These data files should move to the module they belong to. The are, after >> all, "source code" for that module that is "compiler" into resulting >> deliverables, for that module. (But the "source code" language is not Java >> or C, but typically a highly domain specific language or data format, and >> the "compilation" is, often, a specialized transformation.) >> >> This misplacement of the data directory is most visible at code review time. >> When such data is changed, most of the time build-dev (or the new build >> label) is involved, even though this has nothing to do with the build. While >> this is annoying, a worse problem is if the actual team that needs to review >> the patch (i.e., the team owning the module) is missed in the review. >> >> ### Modules reviewed >> >> - [ ] java.base >> - [ ] java.desktop >> - [x] jdk.compiler >> - [ ] java.se > > Magnus Ihse Bursie has updated the pull request incrementally with one > additional commit since the last revision: > > Move to share/data, and move jdwp.spec to java.se The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me. - Marked as reviewed by weijun (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/1611
Re: [OpenJDK 2D-Dev] RFR: 8256888: Client manual test problem list update [v2]
On Thu, 10 Dec 2020 00:37:46 GMT, Phil Race wrote: >> Update the problem list. > > Phil Race has updated the pull request incrementally with one additional > commit since the last revision: > > 8256888: Client manual test problem list update Marked as reviewed by serb (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/1396
[OpenJDK 2D-Dev] Integrated: 8256888: Client manual test problem list update
On Mon, 23 Nov 2020 17:56:03 GMT, Phil Race wrote: > Update the problem list. This pull request has now been integrated. Changeset: f631a990 Author:Phil Race URL: https://git.openjdk.java.net/jdk/commit/f631a990 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8256888: Client manual test problem list update Reviewed-by: serb - PR: https://git.openjdk.java.net/jdk/pull/1396
