Re: [OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021

Reminder. -phil On 9/15/21 11:08 AM, Philip Race wrote: As described below -Phil. Forwarded Message Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th September 2021 Date: Wed, 15 Sep 2021 11:05:09 -0700 From: Philip Race To: client-libs

[OpenJDK 2D-Dev] Retiring this 2d-dev list on 30th September 2021

As described below -Phil. Forwarded Message Subject: Retiring 2d, awt, beans, sound and swing mailing lists on 30th September 2021 Date: Wed, 15 Sep 2021 11:05:09 -0700 From: Philip Race To: client-libs-...@openjdk.java.net Since : 1) The old client groups

[OpenJDK 2D-Dev] Fwd: Project Wakefield announcement and welcome

FYI Forwarded Message Subject:Project Wakefield announcement and welcome Date: Wed, 1 Sep 2021 14:59:30 -0700 From: Philip Race To: wakefield-...@openjdk.java.net Hi all, The project has been recorded in the OpenJDK census : https://openjdk.java.net

[OpenJDK 2D-Dev] FYI: A CFD for a Wayland project has been posted to disc...@openjdk.java.net

https://mail.openjdk.java.net/pipermail/discuss/2021-July/005846.html -phil.

Re: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

PM, Philip Race wrote: Alan, I am not sure this is a known issue. We'll need a lot more details. I figured you would. :-) What is your h+w and OS update ? iMac 27 inch 2020 Radeon Pro 5500 XT 8 GB 11.3.1 Is this all windows in an app or just the first one ? Definitely not just the first

Re: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

window might be fast or slow. It happens with a variety of window classes. In JDK16 and using OpenGL, the content always appears immediately. On Apr 23, 2021, at 1:13 PM, Philip Race wrote: FYI to the wider community that may not subscribe to the client mailing lists, nor appreciate too much

Re: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0

I built with gcc 10.3 https://bugs.openjdk.java.net/browse/JDK-8265373 I expect we can accommodate disabling one more warning to support more compilers. -phil. On 5/4/21 12:31 PM, Florian Weimer wrote: * Phil Race: Upgrade to harfbuzz 2.8 I believe this causes a build failure with GCC

[OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS.

Heads up to anyone who is testing JDK 17 for running apps on macOS. Starting with build 19 [1], JDK 17 for macOS is *temporarily* switched from using OpenGL to using Apple's Metal API for Java 2D rendering. This should be invisible to applications. We expect to revert this temporary switch in

Re: [OpenJDK 2D-Dev] Image parsing spams stack traces to System.err

The real answer was a bug report at bugreport.java.com But never mind - I've submitted https://bugs.openjdk.java.net/browse/JDK-8265603 FWIW I think the prints were there because the developer who added them didn't expect them to be hit unless something went seriously wrong and wanted it to

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

On 3/30/21 11:31 PM, mc36 wrote: please find below, but, again, it's jre17~15, where everything seems fine. Oh that's what you mean by the incomprehensible " please dont! i got ~15 and the issue is gone!" So it was some one-off problem with the build 14 from your distro. I think this

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

current best guess is it is related to how your distro built it .. -phil. On 3/29/21 10:33 PM, Philip Race wrote: On 3/29/21 8:14 PM, mc36 wrote: hi, please dont! i got ~15 and the issue is gone! please don't do what ? (but answering line by line, who knows) thanks, cs Ok. So it looks like

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

. On 3/29/21 6:41 PM, Philip Race wrote: Moving this to the right list. There's lots of missing information in your email. 1) I don't know what a debian sid is. Internet suggests it is some upstream dev version Is this reproducible on any shipping distro ? yesss, it is. https

Re: [OpenJDK 2D-Dev] libfontmanager.so: undefined symbol: hb_font_destroy in openjdk17~14

Moving this to the right list. There's lots of missing information in your email. 1) I don't know what a debian sid is. Internet suggests it is some upstream dev version Is this reproducible on any shipping distro ? 2) Where exactly did you get the openjdk build 17 ? Was it from

Re: [OpenJDK 2D-Dev] Clarification regarding PageFormat and Paper getImageable* functions orientation consideration

There's no bug here from what I am being shown. >"PageFormat showing wrong printer margins in LANDSCAPE orientation” . Really ? But I don't see anywhere the PageFormat is queried for this. Instead the test case digs inside the PageFormat and retrieves the Paper and asks for *its* margins I

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) EA build 10 has been released

All, We have prepared an EA 10 build of Project Lanai for JEP 382 [1] incorporating fixes to feed back during the ongoing code review [2] EA 10 can be downloaded from https://jdk.java.net/lanai/. Note the open issues and testing suggestions given there. Please test with your apps and

Re: [OpenJDK 2D-Dev] Thread safety of SunFontManager.platformFontMap

The map is not expected to be updated after it has been created so it should not need synchronized access. There are a couple of exceptions where it is being updated when some file that is supposed to be there can't be found - a scenario that apparently hasn't been an issue in the 10 years

Re: [OpenJDK 2D-Dev] RFR: 8260931: Implement JEP 382: New macOS Rendering Pipeline [v7]

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

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) FINAL planned EA build has been released

All, The Lanai project has reached the stage where we are aiming to move the JEP [1] to Proposed-To-Target [2] to JDK 17 very soon. We have made one final planned EA release which includes all the latest fixes. So please visit https://jdk.java.net/lanai/ and download the EA 9 build and

[OpenJDK 2D-Dev] Project Lanai (New Metal Java 2D Rendering pipeline for macOS) FINAL planned EA build has been released

All, The Lanai project has reached the stage where we are aiming to move the JEP [1] to Proposed-To-Target [2] to JDK 17 very soon. We have made one final planned EA release which includes all the latest fixes. So please visit https://jdk.java.net/lanai/ and download the EA 9 build and

Re: [OpenJDK 2D-Dev] RFR: 8251854: [macosx] Java forces the use of discrete GPU

From the CSR ; >This change also improves the startup performance, on my current new > laptop mbp 16 + BigSur 11.1 the switching discrete/integrated causes unexpected delays up to 10 seconds. This also has to be a bug. I thought it had gone away. Have we reported that to Apple ? If not we

[OpenJDK 2D-Dev] EA8 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

The EA 8 build of Project Lanai [1] was posted today at https://jdk.java.net/lanai/ EA 8 Build 17-lanai+1-2 (2020/12/12) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. One particular request : To anyone who has a mac still running 10.12 - we don't expect Metal

[OpenJDK 2D-Dev] EA7 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

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:

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

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

Re: [OpenJDK 2D-Dev] RFR: 8247872: Upgrade HarfBuzz to the latest 2.7.2

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

[OpenJDK 2D-Dev] EA6 build of Project Lanai (Java 2D Metal rendering pipeline for macOS) is now posted

I am a bit slow in sending out the announcement, but https://jdk.java.net/lanai/ is now hosting the EA 6 build of Lanai EA 6 Build 16-lanai+2-229 (2020/10/4) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 6 contains the following new bug fixes relative to

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

wrote: - To: Philip Race From: Vipin Mv1/India/IBM Date: 08/31/2020 05:52PM Cc: 2d-dev@openjdk.java.net Subject: Re: [EXTERNAL] Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray Hi Philip, Thanks for the review comments. The testcase test/jdk/java/awt/print/PrinterJob

[OpenJDK 2D-Dev] EA5 build of Project Lanai (Metal rendering pipeline for macOS) is now posted

After some technical hiccups which delayed it, https://jdk.java.net/lanai/ is now hosting the EA 5 build of Lanai EA 5 Build 16-lanai+1-129 (2020/9/7) Please do give it a try (-Dsun.java2d.metal=true) and let us know of issues. EA 5 contains the following new bug fixes relative to EA 4

Re: [OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

As per the notifiication last week, as of NOW there should be NO MORE pushes to the hg://openjdk.java.net/jdk/client forest. --- So accordingly the ABSOLUTE LATEST DROP DEAD time for pushes to jdk/client should be >> 9am PDT Tuesday 1st Sept 2020 << --- -phil. On 8/28/20, 10:5

Re: [OpenJDK 2D-Dev] RFR[8250855]: 'Address reliance on default constructors in the Java 2D APIs'

Right we have started to be consistent using "Constructor for subclasses to call": Also I prefer constructs over creates, even for the concrete classes, eg this : + +/** + * Creates an {@code ImageFilter}. + */ +public ImageFilter() {} + should be "Constructs an {@code

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

it tests. -phil On 8/29/20, 11:10 AM, Philip Race wrote: PS, there's a test case in the bug. Seems like it could be used as the basis for a manual regression test. Make sure you use @requires printer as well as adding the manual and headful keywords and next you'll have to check

Re: [OpenJDK 2D-Dev] RFR: 8252070 Some platform-specific BLIT optimizations are not effective

I note that you change the signature of blitSurfaceData to private. I think this is fine. Since it is only used in this class I imagine whatever reason it was supposed it might need to be over-ridden has never arisen .. But I still had to first go check that it isn't actually used elsewhere !

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

:36 AM, Philip Race wrote: This looks reasonable but we need to test it first before approving it. -phil. On 8/27/20, 6:16 AM, Vipin Mv1 wrote: Hi, Please find below a patch for the following issue. https://bugs.openjdk.java.net/browse/JDK-8234393 http://cr.openjdk.java.net/~aleonard/8234393

[OpenJDK 2D-Dev] IMPORTANT - PLEASE READ - Retiring the jdk/client repo next week

All, Contingent on Project Skara (ie mercurial ->git / githib) going active for the JDK project on schedule on 5th September, we intend to retire the jdk/client repo/forest as part of this transition. In other words, once mercurial is shut down and we move to git there will ONLY be the main

[OpenJDK 2D-Dev] RFR: 8245400: Upgrade to LittleCMS 2.11

Bug : https://bugs.openjdk.java.net/browse/JDK-8245400 Webrev : http://cr.openjdk.java.net/~prr/8245400/ A rotuine 3rd party library upgrade. All platforms build + all tests pass. -phil.

Re: [OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

at it if they want as a separate fix. -phil. On 8/27/20, 12:45 PM, Sergey Bylokhov wrote: Hi, Phil. Probably we could enable WARNINGS_AS_ERRORS_xlc as well? I guess we will need a confirmation from the SAP gurus. On 27.08.2020 12:39, Philip Race wrote: Bug : https://bugs.openjdk.java.net/browse/JDK

[OpenJDK 2D-Dev] RFR: 8074844 : Resolve disabled warnings for libfontmanager

Bug : https://bugs.openjdk.java.net/browse/JDK-8074844 Webrev : http://cr.openjdk.java.net/~prr/8074844/index.html This resolves the disabled compiler warnings in what is now quite a small fontmanager library. I've built windows, mac and linux in our build system and run our full battery of

Re: [OpenJDK 2D-Dev] RFR: 8234393 [macos] printing ignores printer tray

This looks reasonable but we need to test it first before approving it. -phil. On 8/27/20, 6:16 AM, Vipin Mv1 wrote: Hi, Please find below a patch for the following issue. https://bugs.openjdk.java.net/browse/JDK-8234393 http://cr.openjdk.java.net/~aleonard/8234393/webrev.00 Thanks&

Re: [OpenJDK 2D-Dev] RFR: 7183828 Invalid Image Variant when using anything other than BufferedImage

Can you please add an evaluation to the bug report explaining what you intend to do. The submitter of that bug was clearly hoping that we'd support custom Image subclasses and this fix just changes the behaviour from an IAE (or similar) to silently ignoring them. I'm not sure what benefit there

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

On 8/25/20, 4:01 PM, Sergey Bylokhov wrote: It is applied if the "automatic graphics switching" is enabled, if the user disables this feature for the "power adapter" mode, then the discrete graphics will be always used. That's a bit misleading If I disable automatic graphics switching it

Re: [OpenJDK 2D-Dev] RFR: 8251854 [macosx] Java forces the use of discrete GPU

-phil I guess by default they try to "maximize battery life": https://support.apple.com/en-us/HT202043 -- Kevin On 8/24/2020 11:27 PM, Sergey Bylokhov wrote: On 24.08.2020 13:35, Philip Race wrote: Is there any performance cost to doing this ? I'd expect so. Any estimate ?

Re: [OpenJDK 2D-Dev] RFR: 8171303 sun/java2d/pipe/InterpolationQualityTest.java fails on Windows & Linux

This is fine but 1) I like to see the bug under which you fixed it in the @bug list. 2) I am not sure I see how all the various reasons for this test failing can be explained by this. -phil. On 8/25/20, 1:37 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug:

[OpenJDK 2D-Dev] RFR: 8247867: Upgrade to freetype 2.10.2

bug: https://bugs.openjdk.java.net/browse/JDK-8247867 webrev: http://cr.openjdk.java.net/~prr/8247867/ Minor upgrade from 2.10.1 to 2.10.2 All the usual desktop tests pass. the vast majority of the files are touched only with a one line 2019->2020 copyright update made by the freetype devs.

Re: [OpenJDK 2D-Dev] RFR: 8251469 Better cleanup for test/jdk/javax/imageio/SetOutput.java

+1 -phil On 8/15/20, 8:48 PM, Sergey Bylokhov wrote: Hello. Please review the fix for jdk/client. Bug: https://bugs.openjdk.java.net/browse/JDK-8251469 Fix: http://cr.openjdk.java.net/~serb/8251469/webrev.00 One more test which leaks the temp file, because it does not close the IOS stream.

Re: [OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager

path. -phil. On 8/11/20, 2:38 AM, Magnus Ihse Bursie wrote: On 2020-08-10 22:47, Philip Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8251367 webrev: http://cr.openjdk.java.net/~prr/8251367/ When using something other than the java launcher (ie the jpackage launcher) harfbuzz.dll

[OpenJDK 2D-Dev] 8251367: [windows] harfbuzz.dll not found causes failure to load sun.font.SunFontManager

bug: https://bugs.openjdk.java.net/browse/JDK-8251367 webrev: http://cr.openjdk.java.net/~prr/8251367/ When using something other than the java launcher (ie the jpackage launcher) harfbuzz.dll is not found by windows dll loading. So we need to load it explicitly else the Java class that loads

[OpenJDK 2D-Dev] EA4 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

https://jdk.java.net/lanai/ is now hosting the EA 4 build of Lanai Build 16-lanai+1-51 (2020/8/3) List of notable fixed bugs since EA 3 * 8233226: Implement XOR Mode rendering option * 8247564: Lanai - SwingSet2 - Motif LF - UI

[OpenJDK 2D-Dev] RFR: 8240487 : Cleanup whitespace in .cc, .hh, .m, and .mm files

Bug: https://bugs.openjdk.java.net/browse/JDK-8240487 Webrev: http://cr.openjdk.java.net/~prr/8240487/ In advance of the move to Project Skara/git it is desirable to clean up whitespace in source files that are not currently checked by jcheck so we can add these extensions to jcheck at that

Re: [OpenJDK 2D-Dev] [16] RFR JDK-8243674: Remove language tag length limit for iTXt chunk in PNGImageReader

+1 -phil. On 7/30/20, 3:55 PM, Sergey Bylokhov wrote: Hi, Jay. The fix looks fine, but maybe we can to trigger added IIOException(remainingLen < 0) by the test? On 29.07.2020 02:41, Jayathirth D v wrote: Hello All, Please review the following fix for JDK 16: Bug :

Re: [OpenJDK 2D-Dev] RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

-31 10:58, Philip Race wrote: bug: https://bugs.openjdk.java.net/browse/JDK-8250894 webrev : http://cr.openjdk.java.net/~prr/8250894/ Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated out libharfbuzz from libfontmanager, it would be natural for distros to want to link against

[OpenJDK 2D-Dev] RFR: 8250894 : Provide a configure option to build and run against the platform libharfbuzz

bug: https://bugs.openjdk.java.net/browse/JDK-8250894 webrev : http://cr.openjdk.java.net/~prr/8250894/ Since https://bugs.openjdk.java.net/browse/JDK-8249821 has now separated out libharfbuzz from libfontmanager, it would be natural for distros to want to link against the libharfbuzz that they

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

://cr.openjdk.java.net/~ysuenaga/JDK-8249215/webrev.02/ If you are ok this, I will push it to jdk/client. Thanks, Yasumasa On 2020/07/29 10:21, Philip Race wrote: The change in WFontConfiguration looks good but I have no idea what the change in WComponentPeer is supposed to achieve. "new

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

07/29 9:49, Philip Race wrote: On 7/28/20, 5:35 PM, Yasumasa Suenaga wrote: Hi Phil, Thanks for explanation. findFontWithCharset() does not have comments, so I cannot evaluate my proposal whether it breaks important behavior, but I almost agree with your change. However... sequence.allfont

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

ontName = fontDescriptors[0].getNativeName(); +} return fontName; } ``` Thanks, Yasumasa On 2020/07/28 23:43, Philip Race wrote: 1) You assume there is a font with ANSI_CHARSET in the list. I thought I already tried to point out that if the entry looked like this se

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

if (componentFontName.endsWith(charset)) { ``` The following code is pointless as you said, so I agree with you to remove it. if (fontName ==null) { fontName = findFontWithCharset(fontDescriptors,"DEFAULT_CHARSET"); } Thanks, Yasumasa On 2020/07/28 15:15, Philip R

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

this there : if (fontName ==null) { if (fontDescriptors.length >0) { return fontDescriptors[0].getNativeName(); }else { fontName ="Arial,ANSI_CHARSET"; } } Not very satisfactory but then we can remove the comment about maybe returning NULL

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

FAULT_CHARSET does not work at this point. If we do not pass -Dfile.encoding=UTF-8, `charset` in WFontConfiguration::findFontWithCharset is set to "windows-31j" and it can find out valid font when Windows is set to Japanese locale. I can share minidump for further investigation. What sho

Re: [OpenJDK 2D-Dev] RFR (XS) 8250605: Linux x86_32 builds fail after JDK-8249821

OK .. although I hope to come back in JDK 16 and eliminate all disabled warnings from the now much smaller libfontmanager : https://bugs.openjdk.java.net/browse/JDK-8074844 -phil. On 7/27/20, 5:41 AM, Erik Joelsson wrote: Looks good to me. /Erik On 2020-07-27 00:28, Aleksey Shipilev wrote:

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

+1 -phil. On 7/26/20, 9:20 PM, Prasanta Sadhukhan wrote: Hi Phil, On 24-Jul-20 3:48 AM, Philip Race wrote: So the bug is that directly calling ServiceUI.printDialog() was enabling a non-functional properties button on just the Windows platform and you are adding an extra condition

Re: [OpenJDK 2D-Dev] PING: RFR: 8249215: JFrame::setVisible crashed with -Dfile.encoding=UTF-8

Hi, You're avoiding a crash but I don't yet know what *exactly* caused the crash. Some Java code not handling DEFAULT_CHARSET is obviously not the exact cause. This just starts it and something bad presumably happens later in native code. And I don't yet understand why (we think) this

Re: [OpenJDK 2D-Dev] RFR : 8200281: Add missing @Override annotations in ImageIO plugins

approach is fine? Please find the updated webrev with superfluous comments removed : http://cr.openjdk.java.net/~jdv/8200281/webrev.01/ <http://cr.openjdk.java.net/%7Ejdv/8200281/webrev.01/> Thanks, Abhishek *From:*Philip Race *Sent:* Thursday, July 23, 2020 10:37 PM *To:* Kumar Ab

Re: [OpenJDK 2D-Dev] RFR JDK-8246742: ServiceUI.printDialog does not support properties dialog

So the bug is that directly calling ServiceUI.printDialog() was enabling a non-functional properties button on just the Windows platform and you are adding an extra condition to prevent that without harming the goal of JDK-4673406 to have it enabled and functional when invoked by

Re: [OpenJDK 2D-Dev] RFR: 8249821: Separate libharfbuzz from libfontmanager

493-494: Too much indent /Erik On 2020-07-21 14:39, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8249821 Webrev: http://cr.openjdk.java.net/~prr/8249821/ This fix breaks out libharfbuzz from libfontmanager. As well as building I've done extensive testing on all platforms. I

[OpenJDK 2D-Dev] RFR: 8249821: Separate libharfbuzz from libfontmanager

Bug: https://bugs.openjdk.java.net/browse/JDK-8249821 Webrev: http://cr.openjdk.java.net/~prr/8249821/ This fix breaks out libharfbuzz from libfontmanager. As well as building I've done extensive testing on all platforms. I have tweaked the disabled warnings so we don't have un-needed

[OpenJDK 2D-Dev] RFR : 8249725 : testbug: ZeroWithStringBoundsTest.java needs update to copyright header.

Bug: https://bugs.openjdk.java.net/browse/JDK-8249725 The copyright header is missing "All Rights Reserved". This causes a failure in validation builds so we need to fix ASAP. diff diff --git a/test/jdk/java/awt/FontClass/ZeroWidthStringBoundsTest.java

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

On 7/14/20, 8:43 AM, Langer, Christoph wrote: This should probably also be pushed to the client repo. That is not just "probably", it is a definite yes. -phil.

Re: [OpenJDK 2D-Dev] Fwd: Re: RFR : 8248802: Add log helper methods to FontUtilities.java

: Add log helper methods to FontUtilities.java Date: Tue, 14 Jul 2020 14:22:50 + From: Langer, Christoph To: Philip Race , Baesken, Matthias CC: Peter Hull , Jayathirth D v , 2d-dev@openjdk.java.net <2d-dev@openjdk.java.net> Hi, I guess it would make sense to

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

es/sun/awt/FontConfiguration.java:86: FontUtilities.logInfo("Creating standard Font Configuration"); Best regards, Matthias *From:*Philip Race *Sent:* Donnerstag, 9. Juli 2020 19:17 *To:* Baesken, Matthias *Cc:* Peter Hull ; Jayathirth D v ; Langer, Christoph ; 2d-dev@openj

[OpenJDK 2D-Dev] EA3 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

https://jdk.java.net/lanai/ is now hosting the EA 3 build of Lanai This is now JDK16 based since JDK 15 forked for stabilisation. Build 16-lanai+1-11 (2020/7/3) new bugs fixed # 8242950: Files which can't be selected has different color with metal than opengl in JFileChooser

Re: [OpenJDK 2D-Dev] RFR : 8248802: Add log helper methods to FontUtilities.java

I agree. There always should be a call such as FontUtilities.isLogging() test protecting doing unnecessary work. -phil. On 7/9/20, 3:24 AM, Peter Hull wrote: Probably not my place to comment, but, does it matter that it's doing unnecessary work evaluating the argument to logWarning et al, in

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

, Philip Race <mailto:philip.r...@oracle.com>> wrote: one more update to the tests cr.openjdk.java.net/~prr/8240654.2/ <http://cr.openjdk.java.net/%7Eprr/8240654.2/> I added @requires vm.gc.Z per the VM folks, ZGC needs Windows Server 2019 or the same vintage Window 10. if

[OpenJDK 2D-Dev] RFR [JDK15] : 8244818 : Java2D Queue Flusher crash while moving application window to external monitor

Bug : https://bugs.openjdk.java.net/browse/JDK-8244818 Webrev : http://cr.openjdk.java.net/~prr/8244818/ Please review this fix for JDK 15 : This crash was reported recently but we'd not been able to reproduce it until we used Xcode 11.3 to build, in which case it became 100% reproducible.

[OpenJDK 2D-Dev] EA2 build of Project Lanai (Metal rendering pipeline for macOS) is now posted.

Hi all, https://jdk.java.net/lanai/ is now hosting the EA 2 build of Lanai Build 15-lanai+1-157 (2020/6/12) EA 2 contains the following new bug fixes relative to EA 1. * 8247464: Memory Leak in MTLBlitLoops_CopyArea() method *

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

Kim, Until it says in "the JDK" and not "in HotSpot" you have not addressed my main point. Please rename the JEP. -phil. On 6/13/20, 8:48 PM, Kim Barrett wrote: On Jun 10, 2020, at 2:26 AM, Kim Barrett wrote: On Jun 8, 2020, at 4:07 PM, Philip Race wrote

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

the GDIWinSD_Unlock via BitBlt. Not sure this code might be affected by this bug or not. BTW I just realized that the test depends on the blit of Swing backbuffer to the window, it does not force usage of "memory->GDI" blit by itself. On 6/11/20 12:05 pm, Philip Race wrote: You

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

(AnyColor, SrcNoEa, AnyInt) sun.java2d.windows.GDIBlitLoops::Blit(IntRgb, SrcNoEa, "GDI") java.awt.Rectangle[x=0,y=0,width=1920,height=1017] -phil On 6/11/2020 11:35 AM, Sergey Bylokhov wrote: On 6/11/20 9:55 am, Philip Race wrote: I have confirmed hit a different code path. It goes through gen

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

it then it is drawn. With the fix everything is fine. -- Kevin On 6/11/2020 10:48 AM, Philip Race wrote: Updated webrev here http://cr.openjdk.java.net/~prr/8240654.1/index.html The only changes are to the tests - to add -Dsun.java2d.uiScale=1 to the onscreen test and to add printer

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

think I would like this fix anyway. We really don't need to lock down the VM in these cases. -phil. On 6/11/20, 9:55 AM, Philip Race wrote: I have confirmed hit a different code path. It goes through generic 2D s/w loops in this case. ie we don't use GDIBlitLoops at all. The code in sun/java2d

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

, Philip Race wrote: Or, maybe we hit a different code path. I'll check that. uiScale=1 is the way to ensure we hit this code path. -phil. On 6/11/20, 7:44 AM, Philip Race wrote: Can I get clarification here. > I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

tch, and everything looks good with the patch. -- Kevin On 6/10/2020 1:48 PM, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8240654 Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html This is for JDK 15 so review ASAP please since RDP 1 and the test cycle are loom

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

Or, maybe we hit a different code path. I'll check that. uiScale=1 is the way to ensure we hit this code path. -phil. On 6/11/20, 7:44 AM, Philip Race wrote: Can I get clarification here. > I do, and had to run with "-Dsun.java2d.uiScale=1" in order to see

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

now) it doesn’t pass/close the window. Only after I click on Print button and then close print dialog it allows me to click on Pass button. Also how does these tests behave in our internal CI machines? Thanks, Jay On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:philip.r...@oracle.com>> wro

Re: [OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

printer on this test ? But can't you print to file using Windows built in print to pdf ? Also how does these tests behave in our internal CI machines? The printing one is manual so it is never going to pass there. -phil Thanks, Jay On 11-Jun-2020, at 2:18 AM, Philip Race <mailto:phili

[OpenJDK 2D-Dev] RFR: 8240654 : ZGC can cause severe UI application repaint issues

Bug: https://bugs.openjdk.java.net/browse/JDK-8240654 Webrev: http://cr.openjdk.java.net/~prr/8240654/index.html This is for JDK 15 so review ASAP please since RDP 1 and the test cycle are looming. This is not a fix for a JDK bug. It is a bunch of workarounds for a Microsoft Windows bug

Re: [OpenJDK 2D-Dev] RFR: 8246032: Implementation of JEP 347: Adopt C++14 Language Features in HotSpot

Hi Kim, Can we amend the JEP itself to be not solely about hotspot. Since it affects other areas I think that 1) They may need to be compiled with C++14 enabled whether they use new features or not 2) They may want - or need - to adopt C++11 or C++14 features too. You already know that soon

Re: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

remove 8234916? Regards Prasanta On 22-May-20 2:26 AM, Philip Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8244621 Webrev : http://cr.openjdk.java.net/~prr/8244621/ macOS ships some UI fonts which it does not enumerate, all having names beginning with "." It expects you

Re: [OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

/21/20, 2:16 PM, Kevin Rushforth wrote: +1 In case you want to fix it before you push, you have trailing whitespace in the file (jcheck won't complain since it doesn't check .m files, so no worries if you don't). -- Kevin On 5/21/2020 1:56 PM, Philip Race wrote: Bug: https

[OpenJDK 2D-Dev] RFR: 8244621: [macos10.15] Garbled FX printing plus CoreText warnings on Catalina when building with Xcode 11

Bug: https://bugs.openjdk.java.net/browse/JDK-8244621 Webrev : http://cr.openjdk.java.net/~prr/8244621/ macOS ships some UI fonts which it does not enumerate, all having names beginning with "." It expects you to create them using APIs such as

Re: [OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes.

simple text, assume GV ok to use if simple well, there's the the issue that TL should not barf, but it does. -phil. On 5/18/20 5:07 pm, Philip Race wrote: bug : https://bugs.openjdk.java.net/browse/JDK-8245159 webrev: http://cr.openjdk.java.net/~prr/8245159/ TextLayout does not like being

[OpenJDK 2D-Dev] RFR: 8245159: Font.getStringBounds() throws IAE for empty string if the Font has layout attributes.

bug : https://bugs.openjdk.java.net/browse/JDK-8245159 webrev: http://cr.openjdk.java.net/~prr/8245159/ TextLayout does not like being constructed with an empty string, so when we accept a string from the application and use it in creating a TextLayout we need to be check. I looked around for

[OpenJDK 2D-Dev] RFR: 6949753 java/awt/print/PageFormat/PDialogTest.java needs update by removing a infinite loop

Bug: https://bugs.openjdk.java.net/browse/JDK-6949753 webrev : http://cr.openjdk.java.net/~prr/6949753/ Buggy, manual and not very useful. Delete. -phil.

[OpenJDK 2D-Dev] Project Lana EA build now available at https://jdk.java.net/lanai/ - feedback requested.

The first EA build of Project Lanai is available at https://jdk.java.net/lanai/ This is a new Java2D graphics pipeline for macOS. It can run the usual client demos, such as SwingSet2 and J2Ddemo, and even a large app like an IDE, although not without glitches. The EA download page has a link

Re: [OpenJDK 2D-Dev] RFR: 8244224: Implementation of JEP 381: Remove the Solaris and SPARC Ports - (client/desktop)

This is all +1 from me. -phil. On 5/6/20, 5:50 PM, Mikael Vidstedt wrote: Sergey/Shura, thank you for the reviews. I reverted the Jemmy changes, and found some additional Sun Studio cleanups. New webrev here: webrev:

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

On 5/3/20, 4:11 PM, Sergey Bylokhov wrote: On 4/30/20 9:31 am, Philip Race wrote: This test is called MaxAdvance *is max*. My emphasis. So there is no way to check that MaxAdvance *is max* for some predictable values? even for simple char like "W" or "A"? "Chec

Re: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

ping ! -phil. On 4/30/20, 3:08 PM, Philip Race wrote: Updated with a couple of stability fixes : 1) to use invokeAndWait() instead of invokeLater() 2) To skip fonts that don't support the text we are testing. http://cr.openjdk.java.net/~prr/8244113.1 -phil On 4/29/20, 11:56 AM, Philip Race

Re: [OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

Updated with a couple of stability fixes : 1) to use invokeAndWait() instead of invokeLater() 2) To skip fonts that don't support the text we are testing. http://cr.openjdk.java.net/~prr/8244113.1 -phil On 4/29/20, 11:56 AM, Philip Race wrote: bug : https://bugs.openjdk.java.net/browse/JDK

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

test pass is to make changes to what max advance reports and I am saying that we should not do that. It would be artificial and wrong. -phil. On 4/30/20, 9:23 AM, Sergey Bylokhov wrote: On 4/29/20 3:58 pm, Philip Race wrote: the advance of 'm' is a commonly used proxy for the design width of a

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

to "fix the world" here, I am just removing a test that it is pointless to maintain. -phil. On 4/29/20, 2:54 PM, Sergey Bylokhov wrote: On 4/29/20 2:33 pm, Philip Race wrote: Now that is another topic and unrelated to max advance I think a spec update and CSR would be required for

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

Now that is another topic and unrelated to max advance I think a spec update and CSR would be required for getWidths() and I'd still say this test is not worth it. -phil On 4/29/20, 2:21 PM, Sergey Bylokhov wrote: On 4/28/20 4:28 pm, Philip Race wrote: And max advance is NOT only about

[OpenJDK 2D-Dev] RFR: 8244113 : [TESTBUG] java/awt/font/Rotate/RotatedSyntheticBoldTest.java test comments interpreted as args.

bug : https://bugs.openjdk.java.net/browse/JDK-8244113 webrev : http://cr.openjdk.java.net/~prr/8244113/ Apparently jtreg consumes text even from 2 lines later after an @run tag as being args to pass to the program. Test still passes everywhere after the change. -phil.

Re: [OpenJDK 2D-Dev] RFR: 8221305: java/awt/FontMetrics/MaxAdvanceIsMax.java fails on MacOS + Solaris

On 4/28/20, 2:38 PM, Sergey Bylokhov wrote: On 4/28/20 1:28 pm, Philip Race wrote: You mean make sure maxAdvance is always at least as large as the largest returned by getWidths() ? getWidths() is almost as useless as getMaxAdvance(). I grimace every time I look at it and can only imagine

  1   2   3   4   5   6   7   >