From serb at openjdk.java.net Thu Apr 1 00:59:16 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 00:59:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but > it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in Raster because there are so > many possible exceptions and in some cases they rely on other API they call to generate exceptions and > these may have not been documented or documented acc. to some long lost behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that > ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From aghaisas at openjdk.java.net Thu Apr 1 05:04:25 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 1 Apr 2021 05:04:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v2] In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 15:03:54 GMT, Jayathirth D V wrote: >> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Add comment on usage of MTLRenderCommandEncoder src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 821: > 819: * performing copyArea, thats why we need to query encoder with > 820: * appropriate state from EncoderManager and not use > 821: * direct MTLBlitCommandEncoder for texture mapping. Minor : "texture mapping" should be "texture copy" as MTLBlitCommandEncoder cannot be used for texture mapping anyway. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Thu Apr 1 05:49:51 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 05:49:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3] In-Reply-To: References: Message-ID: > In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Comment update ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3283/files - new: https://git.openjdk.java.net/jdk/pull/3283/files/3e1ba4c9..9b4a90ab Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3283&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3283&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3283/head:pull/3283 PR: https://git.openjdk.java.net/jdk/pull/3283 From aghaisas at openjdk.java.net Thu Apr 1 05:58:31 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 1 Apr 2021 05:58:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3] In-Reply-To: References: Message-ID: <8gcd0twVPPyMFVrTL9Rr6AB1LN2y29hNDOA-aAo8M28=.286cd204-00a1-4262-a552-7d2d8bd6fd87@github.com> On Thu, 1 Apr 2021 05:49:51 GMT, Jayathirth D V wrote: >> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Comment update Marked as reviewed by aghaisas (Committer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Thu Apr 1 06:09:14 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 06:09:14 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: <-nssXzOVh4I__oMQjsjYlvgqtQQKm78fr3Xcd_yT0eY=.2a5f9dcd-e2c1-448e-aa41-29f8700385c1@github.com> Message-ID: <9gKWSStKYVNYI7Na3clZxFhbvBeYWmGIClsd0_5vxOc=.d28af83b-4c08-487e-be4e-b2ebda4232cc@github.com> On Wed, 24 Mar 2021 20:44:26 GMT, Alexey Ivanov wrote: >> Since this is windows specific code, I am not sure if system will not have any printers. I guess by default, Microsoft XPS Document Writer, Microsoft Print-to-PDF, Fax are present in printers list. That is the reason we do not have getPrintService() return 0 printer although there may not be any real printer present in windows system...reason for some failure in jtreg test which caused us to use `@key printer `tag in those tests to make real printers are configured. > >> Since this is windows specific code, I am not sure if system will not have any printers. I guess by default, Microsoft XPS Document Writer, Microsoft Print-to-PDF, Fax are present in printers list. > > Yes, that's correct. But you can remove them. You can also configure the image so that these are not installed by default. > >> That is the reason we do not have getPrintService() return 0 printer although there may not be any real printer present in windows system...reason for some failure in jtreg test which caused us to use `@key printer `tag in those tests to make real printers are configured. > > I agree that getting zero printers in Windows is unlikely. But it's still possible. > > Consider the following scenario: Let's assume there are 10 printers in the system. The user removes 5 of them. In this case, `invalidateService()` is called on the instances of `Win32PrintService` which were removed from the system. > > Then the user removes the remaining 5 printers. In this case, `invalidateService()` is not called at all. If an application has references to any of these instances, they will continue to appear operational. However, the flag `isInvalid` in `Win32PrintService` is used in two methods only: `getPrinterState` and `getPrinterStateReasons`. > > This fix is minor, probably this situation never occurs in the real life. > > The difference in handling the deleted services caught my attention. If everyone agrees it's not problem, I'll withdraw the PR and close the bug as _Not an Issue_. Change looks like good practice and needed, eventhough it may occur rarely. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From jdv at openjdk.java.net Thu Apr 1 06:09:14 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 06:09:14 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov wrote: > When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. > > The old print services should be invalidated. src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 159: > 157: for (int j=0; j < printServices.length; j++) { > 158: if ((printServices[j] instanceof Win32PrintService) && > 159: (!printServices[j].equals(defaultPrintService))) { Is this indentation right? I thought we always map newline additional conditions and not add extra indentation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From alexsch at openjdk.java.net Thu Apr 1 06:48:34 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 1 Apr 2021 06:48:34 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows In-Reply-To: References: Message-ID: On Fri, 26 Feb 2021 19:40:22 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. > > The issue had been reported as JDK-8256264 but was reverted because of the regression JDK-8259007 "This test printed a blank page". > > The fix JDK-8256264 scaled coordinates in wPrinterJob.moveTo()/lineTo() methods up and scaled transforms in wPrinterJob.beginPath()/endPath() down. > > The regression was in the WPathGraphics.deviceDrawLine() method which uses wPrinterJob.moveTo()/lineTo() methods without surrounding them with wPrinterJob.beginPath()/endPath() so the line coordinates were only scaled up. > > I tried to put wPrinterJob.beginPath()/endPath() methods around wPrinterJob.moveTo()/lineTo() in the method WPathGraphics.deviceDrawLine() but the line was not drawn at all even without scaling coordinates up and transform down (without JDK-8256264 fix). It looks like GDI treats this case as an empty shape. > > The proposed fix applies path coordinates and transform scaling only in WPathGraphics.convertToWPath() method. > The one more PathPrecisionScaleFactorShapeTest.java manual test is added which checks that all methods that draw paths in WPathGraphics are used: line in WPathGraphics.deviceDrawLine() and SEG_LINETO/SEG_QUADTO/SEG_CUBICTO in WPathGraphics.convertToWPath() . > > The `java/awt/print` and `java/awt/PrintJob` automatic and manual tests were run on Windows 10 Pro with the fix. > > There are two failed automated tests which fail without the fix as well: > java/awt/print/PrinterJob/GlyphPositions.java > java/awt/print/PrinterJob/PSQuestionMark.java > > The following manual tests have issues on my system: > - `java/awt/print/Dialog/PrintDlgPageable.java` java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static" > > - `java/awt/print/PrinterJob/PrintAttributeUpdateTest.java` I select pages radio button, press the print button but the test does not finish and I do not see any other dialogs with pass/fail buttons. > > - `java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java` Tests that there is no ClassCastException thrown in printing checkbox and scrollbar with XAWT. Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html > > > - `java/awt/print/PrinterJob/SecurityDialogTest.java` A windows with instructions is shown but it does not contain print/pass/fail buttons and it is not possible to close the window. > > - The tests below fail with "Error. Parse Exception: Arguments to `manual' option not supported: yesno" message: > java/awt/print/Dialog/DialogOrient.java > java/awt/print/Dialog/DialogType.java > java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java > java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java > java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java > java/awt/print/PrinterJob/PageDialogTest.java > java/awt/print/PrinterJob/PageRanges.java > java/awt/print/PrinterJob/PageRangesDlgTest.java > java/awt/print/PrinterJob/PrintGlyphVectorTest.java > java/awt/print/PrinterJob/PrintLatinCJKTest.java > java/awt/print/PrinterJob/PrintTextTest.java > java/awt/print/PrinterJob/SwingUIText.java > java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java > java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java > java/awt/PrintJob/SaveDialogTitleTest.java This pull request has now been integrated. Changeset: 02287349 Author: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/02287349 Stats: 731 lines in 5 files changed: 728 ins; 0 del; 3 mod 8262470: Printed GlyphVector outline with low DPI has bad quality on Windows Reviewed-by: serb, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/2756 From psadhukhan at openjdk.java.net Thu Apr 1 07:04:30 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 07:04:30 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 05:49:51 GMT, Jayathirth D V wrote: >> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Comment update src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 826: > 824: id interEncoder = > 825: [mtlc.encoderManager getTextureEncoder:interTexture > 826: isSrcOpaque:dstOps->isOpaque Should it not be srcOps->isOpaque? src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 854: > 852: atIndex:MeshVertexBuffer]; > 853: [finalEncoder setFragmentTexture:interTexture atIndex: 0]; > 854: [finalEncoder drawPrimitives:MTLPrimitiveTypeTriangle vertexStart:0 Can't we reuse drawTex2Tex() for this snippet? ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From aivanov at openjdk.java.net Thu Apr 1 12:08:30 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 12:08:30 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 06:04:32 GMT, Jayathirth D V wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. >> >> The old print services should be invalidated. > > src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 159: > >> 157: for (int j=0; j < printServices.length; j++) { >> 158: if ((printServices[j] instanceof Win32PrintService) && >> 159: (!printServices[j].equals(defaultPrintService))) { > > Is this indentation right? I thought we always map newline additional conditions and not add extra indentation. Is it not right? I admit I don't understand what you mean by _map_ here. When the code is written like it was: if ((printServices[j] instanceof Win32PrintService) && (!printServices[j].equals(defaultPrintService))) { ((Win32PrintService)printServices[j]).invalidateService(); } it's hard to scan: it's not clear what is part of the condition and what is the statement inside the if block. I'd prefer to write it like this: if ((printServices[j] instanceof Win32PrintService) && (!printServices[j].equals(defaultPrintService))) { ((Win32PrintService)printServices[j]).invalidateService(); } That is moving the operator to the continuation line which makes it obvious it is a continuation line of the condition and adding a blank line before the statement in the code. It's still not perfect, however; and it changes the author in `blame` output. I indented the continuation line by additional 8 spaces, which is also a common practice in Java, to visually separate the condition and the statement. In fact, it's IDE that updated the formatting, I decided to keep it because it makes the code clearer. I can revert the change to this line if you like. Or I can just add a blank line between the condition and the statement. What is your preference? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 1 12:52:39 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 1 Apr 2021 12:52:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> Message-ID: On Wed, 31 Mar 2021 21:12:37 GMT, Sergey Bylokhov wrote: >> Submitted: https://bugs.openjdk.java.net/browse/JDK-8264428, please rename PR to "8264428: Replace uses of StringBuffer with StringBuilder in java.desktop". > > Looks like this change goes beyond of simple replacement of StringBuffer with StringBuilder. Please update the description of the bug and PR description. I've updated PR description, but I don't have rights to update JIRA. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From jdv at openjdk.java.net Thu Apr 1 13:09:16 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 13:09:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 12:05:30 GMT, Alexey Ivanov wrote: >> src/java.desktop/windows/classes/sun/print/PrintServiceLookupProvider.java line 159: >> >>> 157: for (int j=0; j < printServices.length; j++) { >>> 158: if ((printServices[j] instanceof Win32PrintService) && >>> 159: (!printServices[j].equals(defaultPrintService))) { >> >> Is this indentation right? I thought we always map newline additional conditions and not add extra indentation. > > Is it not right? > I admit I don't understand what you mean by _map_ here. > > When the code is written like it was: > if ((printServices[j] instanceof Win32PrintService) && > (!printServices[j].equals(defaultPrintService))) { > ((Win32PrintService)printServices[j]).invalidateService(); > } > it's hard to scan: it's not clear what is part of the condition and what is the statement inside the if block. > > I'd prefer to write it like this: > if ((printServices[j] instanceof Win32PrintService) > && (!printServices[j].equals(defaultPrintService))) { > > ((Win32PrintService)printServices[j]).invalidateService(); > } > That is moving the operator to the continuation line which makes it obvious it is a continuation line of the condition and adding a blank line before the statement in the code. It's still not perfect, however; and it changes the author in `blame` output. > > I indented the continuation line by additional 8 spaces, which is also a common practice in Java, to visually separate the condition and the statement. In fact, it's IDE that updated the formatting, I decided to keep it because it makes the code clearer. > > I can revert the change to this line if you like. > Or I can just add a blank line between the condition and the statement. > > What is your preference? By mapping i mean same indentation for all conditions in if statement without adding additional indentation for each continuation line like(Basically line without your change of indentation) if ((condition1) && (condition2)) { } or if ((condition1) &&(condition2)) { } I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. If we want to differentiate between if conditions and actual statement execution to improve readability, we can move the statement block to new line like if ((condition1) && (condition2)) { } ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From jdv at openjdk.java.net Thu Apr 1 13:13:12 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 13:13:12 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: Message-ID: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> On Thu, 1 Apr 2021 12:57:44 GMT, Jayathirth D V wrote: >> Is it not right? >> I admit I don't understand what you mean by _map_ here. >> >> When the code is written like it was: >> if ((printServices[j] instanceof Win32PrintService) && >> (!printServices[j].equals(defaultPrintService))) { >> ((Win32PrintService)printServices[j]).invalidateService(); >> } >> it's hard to scan: it's not clear what is part of the condition and what is the statement inside the if block. >> >> I'd prefer to write it like this: >> if ((printServices[j] instanceof Win32PrintService) >> && (!printServices[j].equals(defaultPrintService))) { >> >> ((Win32PrintService)printServices[j]).invalidateService(); >> } >> That is moving the operator to the continuation line which makes it obvious it is a continuation line of the condition and adding a blank line before the statement in the code. It's still not perfect, however; and it changes the author in `blame` output. >> >> I indented the continuation line by additional 8 spaces, which is also a common practice in Java, to visually separate the condition and the statement. In fact, it's IDE that updated the formatting, I decided to keep it because it makes the code clearer. >> >> I can revert the change to this line if you like. >> Or I can just add a blank line between the condition and the statement. >> >> What is your preference? > > By mapping i mean same indentation for all conditions in if statement without adding additional indentation for each continuation line like(Basically line without your change of indentation) > if ((condition1) && > (condition2)) { > } > > or > > if ((condition1) > &&(condition2)) { > } > > I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. > I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. > > If we want to differentiate between if conditions and actual statement execution to improve readability, we can move the statement block to new line like > if ((condition1) && > (condition2)) > { > } I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Thu Apr 1 13:23:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 13:23:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers In-Reply-To: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Thu, 1 Apr 2021 13:10:40 GMT, Jayathirth D V wrote: >> By mapping i mean same indentation for all conditions in if statement without adding additional indentation for each continuation line like(Basically line without your change of indentation) >> if ((condition1) && >> (condition2)) { >> } >> >> or >> >> if ((condition1) >> &&(condition2)) { >> } >> >> I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. >> I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. >> >> If we want to differentiate between if conditions and actual statement execution to improve readability, we can move the statement block to new line like >> if ((condition1) && >> (condition2)) >> { >> } > > I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. > By mapping i mean same indentation for all conditions in if statement? Okay, it's the first time I've come across to such a use of `map`. > I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. Take a look at [DefaultTableCellRenderer.getTableCellRendererComponent](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L201). > I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. What is more important code readability or the strict limit of 80 columns? All in all, all these styles are used throughout `java.desktop` module. I chose to opt for readability in this particular case and the line fits into 80 column limit. Do I revert the change to this line? Any other suggestions? What is your preference? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Thu Apr 1 13:28:48 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 13:28:48 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: Message-ID: <4KcUqRN7pvZOcNMKhtw2DL7-aJMP9ll97SPfF-z3biA=.42acb62e-3417-46c1-afdb-73600a5c3b65@github.com> > When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. > > The old print services should be invalidated. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Revert indentation of if condition continuation line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3151/files - new: https://git.openjdk.java.net/jdk/pull/3151/files/98129416..edc8ab06 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3151&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3151&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3151/head:pull/3151 PR: https://git.openjdk.java.net/jdk/pull/3151 From jdv at openjdk.java.net Thu Apr 1 13:32:24 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 13:32:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: <4KcUqRN7pvZOcNMKhtw2DL7-aJMP9ll97SPfF-z3biA=.42acb62e-3417-46c1-afdb-73600a5c3b65@github.com> References: <4KcUqRN7pvZOcNMKhtw2DL7-aJMP9ll97SPfF-z3biA=.42acb62e-3417-46c1-afdb-73600a5c3b65@github.com> Message-ID: On Thu, 1 Apr 2021 13:28:48 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. >> >> The old print services should be invalidated. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Revert indentation of if condition continuation line Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Thu Apr 1 13:32:24 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 13:32:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Thu, 1 Apr 2021 13:19:07 GMT, Alexey Ivanov wrote: >> I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. > >> By mapping i mean same indentation for all conditions in if statement? > > Okay, it's the first time I've come across to such a use of `map`. > >> I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. > > Take a look at [DefaultTableCellRenderer.getTableCellRendererComponent](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L201). > >> I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. > > What is more important code readability or the strict limit of 80 columns? > > All in all, all these styles are used throughout `java.desktop` module. > I chose to opt for readability in this particular case and the line fits into 80 column limit. > > Do I revert the change to this line? > Any other suggestions? What is your preference? > I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. Done. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From jdv at openjdk.java.net Thu Apr 1 14:15:37 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 14:15:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: > In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: Refactor code to use drawTex2Tex ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3283/files - new: https://git.openjdk.java.net/jdk/pull/3283/files/9b4a90ab..91e068b9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3283&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3283&range=02-03 Stats: 35 lines in 1 file changed: 0 ins; 22 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3283.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3283/head:pull/3283 PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Thu Apr 1 14:15:39 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 1 Apr 2021 14:15:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v3] In-Reply-To: References: Message-ID: <3Tay8fcA5Cu8BslcxVixViLT_ug7OI3Dut4znIYh7DU=.e33d4791-8469-445b-8cf8-6d7fa6652f86@github.com> On Thu, 1 Apr 2021 06:58:27 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Comment update > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 826: > >> 824: id interEncoder = >> 825: [mtlc.encoderManager getTextureEncoder:interTexture >> 826: isSrcOpaque:dstOps->isOpaque > > Should it not be srcOps->isOpaque? Both source and destination are same in copyArea. So isOpaque property will be same. But we use 32 bit non-opaque intermediate texture, so for intermediate texture we should pass JNI_FALSE for isOpaque property. > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 854: > >> 852: atIndex:MeshVertexBuffer]; >> 853: [finalEncoder setFragmentTexture:interTexture atIndex: 0]; >> 854: [finalEncoder drawPrimitives:MTLPrimitiveTypeTriangle vertexStart:0 > > Can't we reuse drawTex2Tex() for this snippet? Thanks for the suggestion Prasanta, yes we should refactor code to use drawTex2Tex. I have updated the PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From avu at openjdk.java.net Thu Apr 1 14:46:51 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 1 Apr 2021 14:46:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] Message-ID: Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. ------------- Commit messages: - 8258788: incorrect response to change in window insets [lanai] Changes: https://git.openjdk.java.net/jdk/pull/3308/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8258788 Stats: 31 lines in 7 files changed: 16 ins; 13 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308 From shade at openjdk.java.net Thu Apr 1 14:55:24 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 1 Apr 2021 14:55:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <27yKI-MoNpdtE7_qYEHLNj-tmphsEvwwT7NunRjEY5c=.d585ed9c-b74c-4b82-8c24-fca05d944f58@github.com> Message-ID: <7xA0-f_B9XNpEBl0l9tpBx8Q_jAbS2cKIKFKu01OSVE=.71194289-36fe-4768-b753-7c298d7ee349@github.com> On Thu, 1 Apr 2021 12:48:52 GMT, Andrey Turbanov wrote: >> Looks like this change goes beyond of simple replacement of StringBuffer with StringBuilder. Please update the description of the bug and PR description. > > I've updated PR description, but I don't have rights to update JIRA. I updated the bug synopsis in JIRA. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From serb at openjdk.java.net Thu Apr 1 15:21:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 15:21:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:38:52 GMT, Alexey Ushakov wrote: > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. Is it possible to automatically test it? src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1171: > 1169: layer.leftInset = (jint)(screenContentRect.origin.x - frame.origin.x); > 1170: } > 1171: } Can you check that it will work in the "new" tabbed mode on big sur as well? Probably it is possible to swap coordinates during rendering in the layer and get rid of this field? ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From psadhukhan at openjdk.java.net Thu Apr 1 15:54:21 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 1 Apr 2021 15:54:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:15:37 GMT, Jayathirth D V wrote: >> In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. > > Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: > > Refactor code to use drawTex2Tex Marked as reviewed by psadhukhan (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From serb at openjdk.java.net Thu Apr 1 17:32:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 1 Apr 2021 17:32:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Thu, 1 Apr 2021 13:28:50 GMT, Alexey Ivanov wrote: >>> By mapping i mean same indentation for all conditions in if statement? >> >> Okay, it's the first time I've come across to such a use of `map`. >> >>> I have not come across code in java.desktop where we add indentation at each continuation line of 'if' condition. >> >> Take a look at [DefaultTableCellRenderer.getTableCellRendererComponent](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/table/DefaultTableCellRenderer.java#L201). >> >>> I understand difficulty to scan without indentation but then in cases where we have multiple lines on continuation line in if statement we will easily hit 80 characters limit. >> >> What is more important code readability or the strict limit of 80 columns? >> >> All in all, all these styles are used throughout `java.desktop` module. >> I chose to opt for readability in this particular case and the line fits into 80 column limit. >> >> Do I revert the change to this line? >> Any other suggestions? What is your preference? > >> I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. > > Done. I do not suggest that the change should be moved forth and back, but I think that the second conditions should always be shifted, and if this causes 80 chars overflow then some other line split/rename/etc should be done to prevent that. Recent example of such style...: if ((getColorSpaceType (p) == ColorSpace.TYPE_RGB) && (getData (p, icSigMediaWhitePointTag) != null) && (getData (p, icSigRedColorantTag) != null) && (getData (p, icSigGreenColorantTag) != null) && (getData (p, icSigBlueColorantTag) != null) && (getData (p, icSigRedTRCTag) != null) && (getData (p, icSigGreenTRCTag) != null) && (getData (p, icSigBlueTRCTag) != null)) { thisProfile = new ICC_ProfileRGB (p); Is that really looks fine? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Thu Apr 1 17:54:21 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 1 Apr 2021 17:54:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Thu, 1 Apr 2021 17:29:08 GMT, Sergey Bylokhov wrote: >>> I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. >> >> Done. > > I do not suggest that the change should be moved forth and back, but I think that the second conditions should always be shifted, and if this causes 80 chars overflow then some other line split/rename/etc should be done to prevent that. > > Recent example of such style...: > if ((getColorSpaceType (p) == ColorSpace.TYPE_RGB) && > (getData (p, icSigMediaWhitePointTag) != null) && > (getData (p, icSigRedColorantTag) != null) && > (getData (p, icSigGreenColorantTag) != null) && > (getData (p, icSigBlueColorantTag) != null) && > (getData (p, icSigRedTRCTag) != null) && > (getData (p, icSigGreenTRCTag) != null) && > (getData (p, icSigBlueTRCTag) != null)) { > thisProfile = new ICC_ProfileRGB (p); > > Is that really looks fine? This looks even worse than the case in this PR which has only two conditions. If it'd been the new code, I wouldn't have agreed to revert indentation. Let's wait for another opinion? To make it clear, you're for keeping the indentation as it was in the original PR to visually separate condition from the statement in the if block. Do I get it right, @mrserb? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From prr at openjdk.java.net Thu Apr 1 20:27:37 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 1 Apr 2021 20:27:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2] In-Reply-To: References: Message-ID: > https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but > it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in Raster because there are so > many possible exceptions and in some cases they rely on other API they call to generate exceptions and > these may have not been documented or documented acc. to some long lost behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that > ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8255800: Raster creation methods need some specification clean up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3223/files - new: https://git.openjdk.java.net/jdk/pull/3223/files/07424a32..85148fd5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3223&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3223&range=00-01 Stats: 5 lines in 2 files changed: 1 ins; 3 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3223/head:pull/3223 PR: https://git.openjdk.java.net/jdk/pull/3223 From prr at openjdk.java.net Thu Apr 1 20:27:37 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 1 Apr 2021 20:27:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 00:56:41 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255800: Raster creation methods need some specification clean up > > Marked as reviewed by serb (Reviewer). I've updated the PR with one very minor typo correction and a removal of a duplicate throws clause. Also I've prepared a draft CSR which needs to be reviewed https://bugs.openjdk.java.net/browse/JDK-8264625 ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From serb at openjdk.java.net Fri Apr 2 00:16:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 00:16:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Thu, 1 Apr 2021 17:29:08 GMT, Sergey Bylokhov wrote: >>> I would prefer if you revert this line or if we want to put emphasis on readability moving '{' to new line also seems fine. >> >> Done. > > I do not suggest that the change should be moved forth and back, but I think that the second conditions should always be shifted, and if this causes 80 chars overflow then some other line split/rename/etc should be done to prevent that. > > Recent example of such style...: > if ((getColorSpaceType (p) == ColorSpace.TYPE_RGB) && > (getData (p, icSigMediaWhitePointTag) != null) && > (getData (p, icSigRedColorantTag) != null) && > (getData (p, icSigGreenColorantTag) != null) && > (getData (p, icSigBlueColorantTag) != null) && > (getData (p, icSigRedTRCTag) != null) && > (getData (p, icSigGreenTRCTag) != null) && > (getData (p, icSigBlueTRCTag) != null)) { > thisProfile = new ICC_ProfileRGB (p); > > Is that really looks fine? > To make it clear, you're for keeping the indentation as it was in the original PR to visually separate condition from the statement in the if block. Do I get it right, @mrserb? I think it looks better. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From serb at openjdk.java.net Fri Apr 2 01:59:06 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 01:59:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v2] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Fri, 2 Apr 2021 00:12:58 GMT, Sergey Bylokhov wrote: >> I do not suggest that the change should be moved forth and back, but I think that the second conditions should always be shifted, and if this causes 80 chars overflow then some other line split/rename/etc should be done to prevent that. >> >> Recent example of such style...: >> if ((getColorSpaceType (p) == ColorSpace.TYPE_RGB) && >> (getData (p, icSigMediaWhitePointTag) != null) && >> (getData (p, icSigRedColorantTag) != null) && >> (getData (p, icSigGreenColorantTag) != null) && >> (getData (p, icSigBlueColorantTag) != null) && >> (getData (p, icSigRedTRCTag) != null) && >> (getData (p, icSigGreenTRCTag) != null) && >> (getData (p, icSigBlueTRCTag) != null)) { >> thisProfile = new ICC_ProfileRGB (p); >> >> Is that really looks fine? > >> To make it clear, you're for keeping the indentation as it was in the original PR to visually separate condition from the statement in the if block. Do I get it right, @mrserb? > > I think it looks better. BTW another solution is to move { to the next line if the previous statement was split across few lines. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From avu at openjdk.java.net Fri Apr 2 11:44:52 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 2 Apr 2021 11:44:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v2] In-Reply-To: References: Message-ID: > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8258788: incorrect response to change in window insets [lanai] Added regression test ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/afab7f43..cfe15982 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=00-01 Stats: 165 lines in 1 file changed: 165 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308 From avu at openjdk.java.net Fri Apr 2 11:44:53 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 2 Apr 2021 11:44:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: Message-ID: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> On Thu, 1 Apr 2021 15:15:32 GMT, Sergey Bylokhov wrote: > Is it possible to automatically test it? Yes, just added the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From kcr at openjdk.java.net Fri Apr 2 11:49:24 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 2 Apr 2021 11:49:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v2] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 11:44:52 GMT, Alexey Ushakov wrote: >> Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. > > Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: > > 8258788: incorrect response to change in window insets [lanai] > > Added regression test test/jdk/java/awt/Window/FullWindowContentTest/FullWindowContentRenderTest.java line 9: > 7: * published by the Free Software Foundation. Oracle designates this > 8: * particular file as subject to the "Classpath" exception as provided > 9: * by Oracle in the LICENSE file that accompanied this code. Tests should not have the "Classpath" exception. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From avu at openjdk.java.net Fri Apr 2 12:05:48 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 2 Apr 2021 12:05:48 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3] In-Reply-To: References: Message-ID: <0w-R2VFWCvc_jmJSFxgmDNAvkGZnZSXwIuVoduugYA8=.7cb7d8a4-f31e-4973-a9ed-21bfd89cc100@github.com> > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision: 8258788: incorrect response to change in window insets [lanai] Corrected copyrights ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/cfe15982..52fc75e7 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308 From serb at openjdk.java.net Fri Apr 2 21:06:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 21:06:30 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 20:27:37 GMT, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but >> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. >> I've spent a lot of time on what is just small number of factory methods in Raster because there are so >> many possible exceptions and in some cases they rely on other API they call to generate exceptions and >> these may have not been documented or documented acc. to some long lost behavior. >> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that >> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about >> always has to be an internal bug ! >> >> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of >> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 >> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException >> to IllegalArgumentException. >> JCK conformance tests still pass so they must not test those conditions. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8255800: Raster creation methods need some specification clean up Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From aivanov at openjdk.java.net Fri Apr 2 21:27:28 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 2 Apr 2021 21:27:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021 13:22:07 GMT, Alexander Zuev wrote: > Fix updated after first round of review. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 260: > 258: > 259: /** > 260: * Icon for a file, directory, or folder as it would be displayed in *Returns an icon* for a file? src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 276: > 274: * > 275: * @param f a File object > 276: * @param size width and height of the icon in pixels Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16?16 icon should actually be 32?32 if the scale factor of the current display is 200%. Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, *virtual pixels*. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From prr at openjdk.java.net Fri Apr 2 22:40:53 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 2 Apr 2021 22:40:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v3] In-Reply-To: References: Message-ID: <-_OCU44Hmti3PnpHsVOGVlJJl3tTNP46r0UTe_-SB9w=.ea3f5332-7dce-4a56-8fb1-6bae1285b033@github.com> > https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but > it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in Raster because there are so > many possible exceptions and in some cases they rely on other API they call to generate exceptions and > these may have not been documented or documented acc. to some long lost behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that > ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. Phil Race has updated the pull request incrementally with one additional commit since the last revision: 8255800: Raster creation methods need some specification clean up ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3223/files - new: https://git.openjdk.java.net/jdk/pull/3223/files/85148fd5..ba2ab76c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3223&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3223&range=01-02 Stats: 29 lines in 2 files changed: 27 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3223.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3223/head:pull/3223 PR: https://git.openjdk.java.net/jdk/pull/3223 From prr at openjdk.java.net Fri Apr 2 22:40:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 2 Apr 2021 22:40:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v2] In-Reply-To: References: Message-ID: <2rxG8kytiF9AJpKt79UqfLxJaWKwruLNgvn3SMq1JuQ=.fc22b433-041b-4515-be16-74862a6e267c@github.com> On Fri, 2 Apr 2021 21:03:30 GMT, Sergey Bylokhov wrote: >> Phil Race has updated the pull request incrementally with one additional commit since the last revision: >> >> 8255800: Raster creation methods need some specification clean up > > Marked as reviewed by serb (Reviewer). I updated the fix with some additional checks. This is implementation only - doesn't affect the spec clarification. The problem was that without these new upfront checks for overflow of width+location.x, then on systems without enough memory/swap you'd get an OOME before you got to the place where overflow was checked. ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From serb at openjdk.java.net Fri Apr 2 22:46:41 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 2 Apr 2021 22:46:41 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 15:50:50 GMT, Prasanta Sadhukhan wrote: >> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor code to use drawTex2Tex > > Marked as reviewed by psadhukhan (Reviewer). Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap? ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Sat Apr 3 03:00:17 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Sat, 3 Apr 2021 03:00:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 22:43:36 GMT, Sergey Bylokhov wrote: > Just curious how this new "round trip" will affect the performance when the clip is set and when not? is it cheap? I am not getting what do you mean by 'new "round trip" '. Please elaborate. Regarding performance metrics i have captured the details in the bug and there is no degradation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From serb at openjdk.java.net Sat Apr 3 03:54:11 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 3 Apr 2021 03:54:11 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 02:56:48 GMT, Jayathirth D V wrote: > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > Regarding performance metrics i have captured the details in the bug and there is no degradation. The new code path which takes care of the clip, if there is no degradation means that we get it for free? ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Sat Apr 3 05:05:27 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Sat, 3 Apr 2021 05:05:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 03:51:29 GMT, Sergey Bylokhov wrote: > > I am not getting what do you mean by 'new "round trip" '. Please elaborate. > > Regarding performance metrics i have captured the details in the bug and there is no degradation. > > The new code path which takes care of the clip, if there is no degradation means that we get it for free? Before this change we used to get blitEncoder from same commandbuffer(and same CommandQueue) as we are doing now. And then commit the commandbuffer, so from computational perspective we are not holding or doing anything extra in new implementation. We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. Since we are not seeing any difference in performance numbers (especially in swingmark where we do lot of scrolling/copyArea) we are basically getting clipping in copyArea without any degradation. Also in Netbeans i have done good amount scrolling test and i dont see any degradation. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From serb at openjdk.java.net Sat Apr 3 05:33:22 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 3 Apr 2021 05:33:22 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 05:02:24 GMT, Jayathirth D V wrote: > We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Sat Apr 3 05:39:25 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Sat, 3 Apr 2021 05:39:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov wrote: > > We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. > > It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. Exactly i suspect we are not hitting threshold of GPU computing in our tests. If we hit GPU threshold with larger clip bounds i expect performance to be on higher side after the fix. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From github.com+76791+alblue at openjdk.java.net Sat Apr 3 22:11:53 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 3 Apr 2021 22:11:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop Message-ID: 8264680: Use the blessed modifier order in java.desktop ------------- Commit messages: - 8264680: Use the blessed modifier order in java.desktop Changes: https://git.openjdk.java.net/jdk/pull/3337/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264680 Stats: 14 lines in 11 files changed: 0 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jdk/pull/3337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3337/head:pull/3337 PR: https://git.openjdk.java.net/jdk/pull/3337 From github.com+76791+alblue at openjdk.java.net Sat Apr 3 22:28:54 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Sat, 3 Apr 2021 22:28:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: References: Message-ID: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> > 8264680: Use the blessed modifier order in java.desktop Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: Additionally remove detritus from PNGImageDecoder.java ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3337/files - new: https://git.openjdk.java.net/jdk/pull/3337/files/1fb0fe1b..7bb8d9dd Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3337&range=00-01 Stats: 120 lines in 1 file changed: 0 ins; 113 del; 7 mod Patch: https://git.openjdk.java.net/jdk/pull/3337.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3337/head:pull/3337 PR: https://git.openjdk.java.net/jdk/pull/3337 From serb at openjdk.java.net Sun Apr 4 08:01:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 4 Apr 2021 08:01:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: <-SCBgCyxuS50ZA6JNjGNqPNTf1Xpfe7cA1f7ui_vrJI=.8fe36cc5-7f24-4198-9723-f05021b73617@github.com> On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From kizune at openjdk.java.net Sun Apr 4 08:12:07 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Sun, 4 Apr 2021 08:12:07 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From jdv at openjdk.java.net Sun Apr 4 10:04:06 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Sun, 4 Apr 2021 10:04:06 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 05:30:12 GMT, Sergey Bylokhov wrote: >>> > I am not getting what do you mean by 'new "round trip" '. Please elaborate. >>> > Regarding performance metrics i have captured the details in the bug and there is no degradation. >>> >>> The new code path which takes care of the clip, if there is no degradation means that we get it for free? >> >> Before this change we used to get blitEncoder from same commandbuffer(and same CommandQueue) as we are doing now. And then commit the commandbuffer, so from computational perspective we are not holding or doing anything extra in new implementation. We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. >> >> Since we are not seeing any difference in performance numbers (especially in swingmark where we do lot of scrolling/copyArea) we are basically getting clipping in copyArea without any degradation. Also in Netbeans i have done good amount scrolling test and i dont see any degradation. Also i expected improvement in performance (we are seeing little improvement in swingmark numbers) because we are actually doing less amount of copy operation now. > >> We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. > > It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. @mrserb Are there any more inputs/review comments? ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From serb at openjdk.java.net Sun Apr 4 21:54:45 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 4 Apr 2021 21:54:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264475: CopyArea ignores clip state in metal rendering pipeline [v4] In-Reply-To: References: Message-ID: On Sun, 4 Apr 2021 10:00:16 GMT, Jayathirth D V wrote: >>> We need to use appropriate encoder(where scissor is set) to honour clip in copyArea. >> >> It is quite interesting that blitting with or without clipping does not have any difference. thank you for confirmation. but probably our perf tests are not good enough. > > @mrserb Are there any more inputs/review comments? nop, it is fine. ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From jdv at openjdk.java.net Mon Apr 5 05:32:43 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Mon, 5 Apr 2021 05:32:43 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264475: CopyArea ignores clip state in metal rendering pipeline In-Reply-To: References: Message-ID: On Wed, 31 Mar 2021 07:27:45 GMT, Jayathirth D V wrote: > In MTLBlitLoops.copyArea() we use standalone encoder which has no clip state information because of which we ignore clip parameters set in rect clip and shape clip. We need to query and use encoders from EncoderManager to honour clip states in copyArea. This pull request has now been integrated. Changeset: 0039c18e Author: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/0039c18e Stats: 41 lines in 2 files changed: 24 ins; 0 del; 17 mod 8264475: CopyArea ignores clip state in metal rendering pipeline 8251036: SwingSet2 - Dragging internal frame inside jframe leaves artifacts with MetalLookAndFeel Reviewed-by: aghaisas, psadhukhan ------------- PR: https://git.openjdk.java.net/jdk/pull/3283 From avu at openjdk.java.net Mon Apr 5 10:32:54 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Mon, 5 Apr 2021 10:32:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 15:18:21 GMT, Sergey Bylokhov wrote: > Can you check that it will work in the "new" tabbed mode on big sur as well? Could you suggest any working test scenario? My simple test (below) just hangs even with OGL: import java.awt.FlowLayout; import java.util.Objects; import javax.swing.*; import javax.swing.border.EmptyBorder; public class TestWindowInsets extends JDialog { public TestWindowInsets() { JComponent contentPane = (JComponent) getContentPane(); contentPane.setBorder(new EmptyBorder(50, 50, 50, 50)); JButton b = new JButton("Test"); b.addActionListener(e -> toggle()); add(b); JButton c = new JButton("Win"); c.addActionListener(e -> win()); add(c); setLayout(new FlowLayout()); setSize(800, 600); setVisible(true); } void toggle() { SwingUtilities.invokeLater(() -> { JRootPane rp = getRootPane(); String name = "apple.awt.fullWindowContent"; Object value = rp.getClientProperty(name); if (Objects.equals(value, "true")) { value = "false"; } else { value = "true"; } rp.putClientProperty(name, value); }); } void win() { SwingUtilities.invokeLater(TestWindowInsets::new); } public static void main(String[] args) { SwingUtilities.invokeLater(TestWindowInsets::new); } } ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From avu at openjdk.java.net Mon Apr 5 10:37:52 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Mon, 5 Apr 2021 10:37:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3] In-Reply-To: References: Message-ID: On Mon, 5 Apr 2021 10:29:20 GMT, Alexey Ushakov wrote: >> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 1171: >> >>> 1169: layer.leftInset = (jint)(screenContentRect.origin.x - frame.origin.x); >>> 1170: } >>> 1171: } >> >> Can you check that it will work in the "new" tabbed mode on big sur as well? Probably it is possible to swap coordinates during rendering in the layer and get rid of this field? > >> Can you check that it will work in the "new" tabbed mode on big sur as well? > > Could you suggest any working test scenario? My simple test (below) just hangs even with OGL: > > import java.awt.FlowLayout; > import java.util.Objects; > import javax.swing.*; > import javax.swing.border.EmptyBorder; > > public class TestWindowInsets > extends JDialog > { > > public TestWindowInsets() > { > JComponent contentPane = (JComponent) getContentPane(); > contentPane.setBorder(new EmptyBorder(50, 50, 50, 50)); > JButton b = new JButton("Test"); > b.addActionListener(e -> toggle()); > add(b); > JButton c = new JButton("Win"); > c.addActionListener(e -> win()); > add(c); > > setLayout(new FlowLayout()); > setSize(800, 600); > > setVisible(true); > > } > > void toggle() > { > SwingUtilities.invokeLater(() -> { > JRootPane rp = getRootPane(); > String name = "apple.awt.fullWindowContent"; > Object value = rp.getClientProperty(name); > if (Objects.equals(value, "true")) { > value = "false"; > } else { > value = "true"; > } > rp.putClientProperty(name, value); > }); > } > > void win() > { > SwingUtilities.invokeLater(TestWindowInsets::new); > } > > public static void main(String[] args) > { > SwingUtilities.invokeLater(TestWindowInsets::new); > } > } > Probably it is possible to swap coordinates during rendering in the layer and get rid of this field? I don't see a way how we can do it. Because of the inverted y coordinate in metal, we need to place the origin of the drawing with the appropriate offset that depends on the title height, even if we invert the y coordinate to match java2d coordinate system. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From sgehwolf at openjdk.java.net Tue Apr 6 09:46:16 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 09:46:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt In-Reply-To: References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com> Message-ID: On Wed, 31 Mar 2021 20:37:32 GMT, Sergey Bylokhov wrote: >> The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being linked into one native image. >> >> Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests running too. >> >> Thoughts? > > Marked as reviewed by serb (Reviewer). @mrserb Thanks for the review! ------------- PR: https://git.openjdk.java.net/jdk/pull/3155 From sgehwolf at openjdk.java.net Tue Apr 6 09:46:17 2021 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Tue, 6 Apr 2021 09:46:17 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt In-Reply-To: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com> References: <08GQSw2xtXS6dK733iJJeozFOcykbE9odAaj84HqDo0=.9eb0c33f-9ee7-460a-b941-392797abb691@github.com> Message-ID: On Tue, 23 Mar 2021 15:18:13 GMT, Severin Gehwolf wrote: > The suggestion is to rename 'jvm' variable in `libjavajpeg` to `the_jvm` so this conflict no longer occurs when `libjavajpeg.a` and `libawt.a` are being linked into one native image. > > Testing: test/jdk/javax/imageio jtreg tests. GHA pre-integration tests running too. > > Thoughts? This pull request has now been integrated. Changeset: eb6330e4 Author: Severin Gehwolf URL: https://git.openjdk.java.net/jdk/commit/eb6330e4 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod 8264047: Duplicate global variable 'jvm' in libjavajpeg and libawt Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3155 From jdv at openjdk.java.net Tue Apr 6 12:08:27 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 6 Apr 2021 12:08:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: >>> Is it possible to automatically test it? >> >> Yes, just added the test. > >> > Is it possible to automatically test it? >> >> Yes, just added the test. > > @avu Test passes without fix also. Verified test case attached in JBS : https://bugs.openjdk.java.net/browse/JDK-8258788 . I see that fix resolves identified issue in JBS. Also jtreg and JCK test run is green with and without Metal API validation flags. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From jdv at openjdk.java.net Tue Apr 6 12:08:27 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 6 Apr 2021 12:08:27 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Fri, 2 Apr 2021 11:41:12 GMT, Alexey Ushakov wrote: > > Is it possible to automatically test it? > > Yes, just added the test. @avu Test passes without fix also. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From avu at openjdk.java.net Tue Apr 6 12:54:26 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Tue, 6 Apr 2021 12:54:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Fri, 2 Apr 2021 11:41:12 GMT, Alexey Ushakov wrote: >> Is it possible to automatically test it? > >> Is it possible to automatically test it? > > Yes, just added the test. > @avu Test passes without fix also. @jayathirthrao Could you provide the details about your configuration along with parameters passed to jtreg ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From azvegint at openjdk.java.net Tue Apr 6 14:19:28 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 6 Apr 2021 14:19:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264680: Use the blessed modifier order in java.desktop [v2] In-Reply-To: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> References: <7tWzZRpM_-C5E35SuC4CkciMAmF7oLYeoXrXLEB0XEo=.138dfad3-dc19-4283-9804-0365c9dddba3@github.com> Message-ID: On Sat, 3 Apr 2021 22:28:54 GMT, Alex Blewitt wrote: >> 8264680: Use the blessed modifier order in java.desktop > > Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision: > > Additionally remove detritus from PNGImageDecoder.java Marked as reviewed by azvegint (Reviewer). src/java.desktop/share/classes/sun/awt/image/PNGImageDecoder.java line 2: > 1: /* > 2: * Copyright (c) 1999, 2021, Oracle and/or its affiliates. All rights reserved. Copyright year in other files might be updated as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From aghaisas at openjdk.java.net Tue Apr 6 14:19:45 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 6 Apr 2021 14:19:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction Message-ID: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Refer JBS for 3 issues that this PR addresses. In addition, I have corrected an erroneous free() call in the same method I was cleaning up. ------------- Commit messages: - 8263363 - cleanup Changes: https://git.openjdk.java.net/jdk/pull/3357/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8263363 Stats: 21 lines in 3 files changed: 1 ins; 16 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357 From jdv at openjdk.java.net Tue Apr 6 14:45:17 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 6 Apr 2021 14:45:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Tue, 6 Apr 2021 12:03:14 GMT, Jayathirth D V wrote: > > > Is it possible to automatically test it? > > > > > > Yes, just added the test. > > @avu Test passes without fix also. @aghaisas Please verify the regression test behavior from your end also. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From jdv at openjdk.java.net Tue Apr 6 14:45:16 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Tue, 6 Apr 2021 14:45:16 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Tue, 6 Apr 2021 12:51:47 GMT, Alexey Ushakov wrote: > > @avu Test passes without fix also. > > @jayathirthrao Could you provide the details about your configuration along with parameters passed to jtreg ? @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel Iris Graphics 6100. jtreg command i am using "jtreg -jdk: -Dsun.java2d.metal=true " ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From azvegint at openjdk.java.net Tue Apr 6 16:04:33 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Tue, 6 Apr 2021 16:04:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v2] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Tue, 30 Mar 2021 19:05:37 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139: > 137: @Override > 138: public String toString() { > 139: StringBuilder buf = new StringBuilder(super.toString()); Looks like this is the only file where copyright year is not updated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Tue Apr 6 20:38:57 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 6 Apr 2021 20:38:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: Message-ID: > When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. > > The old print services should be invalidated. Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: Add a blank line to separate condition from body ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3151/files - new: https://git.openjdk.java.net/jdk/pull/3151/files/edc8ab06..774e4074 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3151&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3151&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3151.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3151/head:pull/3151 PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Tue Apr 6 20:38:58 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 6 Apr 2021 20:38:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Fri, 2 Apr 2021 01:56:37 GMT, Sergey Bylokhov wrote: >>> To make it clear, you're for keeping the indentation as it was in the original PR to visually separate condition from the statement in the if block. Do I get it right, @mrserb? >> >> I think it looks better. > > BTW another solution is to move { to the next line if the previous statement was split across few lines. I added a blank line between the condition and the body. Does it look good? @mrserb, @jayathirthrao ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From aivanov at openjdk.java.net Tue Apr 6 20:42:24 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Tue, 6 Apr 2021 20:42:24 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Tue, 6 Apr 2021 20:35:09 GMT, Alexey Ivanov wrote: >> BTW another solution is to move { to the next line if the previous statement was split across few lines. > > I added a blank line between the condition and the body. > Does it look good? @mrserb, @jayathirthrao [Code Conventions for Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) say, ?Line wrapping for `if` statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult.? (It's the second to last block on the page.) ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From serb at openjdk.java.net Wed Apr 7 00:40:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 00:40:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v3] In-Reply-To: References: Message-ID: <8opSxuL2yn4qYH2HHm_UcL6cZqHgjiBWKUEbwljL9ow=.a6478e67-a2d2-4adb-805b-f45bfb38a25e@github.com> On Mon, 5 Apr 2021 10:34:21 GMT, Alexey Ushakov wrote: >>> Can you check that it will work in the "new" tabbed mode on big sur as well? >> >> Could you suggest any working test scenario? My simple test (below) just hangs even with OGL: >> >> import java.awt.FlowLayout; >> import java.util.Objects; >> import javax.swing.*; >> import javax.swing.border.EmptyBorder; >> >> public class TestWindowInsets >> extends JDialog >> { >> >> public TestWindowInsets() >> { >> JComponent contentPane = (JComponent) getContentPane(); >> contentPane.setBorder(new EmptyBorder(50, 50, 50, 50)); >> JButton b = new JButton("Test"); >> b.addActionListener(e -> toggle()); >> add(b); >> JButton c = new JButton("Win"); >> c.addActionListener(e -> win()); >> add(c); >> >> setLayout(new FlowLayout()); >> setSize(800, 600); >> >> setVisible(true); >> >> } >> >> void toggle() >> { >> SwingUtilities.invokeLater(() -> { >> JRootPane rp = getRootPane(); >> String name = "apple.awt.fullWindowContent"; >> Object value = rp.getClientProperty(name); >> if (Objects.equals(value, "true")) { >> value = "false"; >> } else { >> value = "true"; >> } >> rp.putClientProperty(name, value); >> }); >> } >> >> void win() >> { >> SwingUtilities.invokeLater(TestWindowInsets::new); >> } >> >> public static void main(String[] args) >> { >> SwingUtilities.invokeLater(TestWindowInsets::new); >> } >> } > >> Probably it is possible to swap coordinates during rendering in the layer and get rid of this field? > > I don't see a way how we can do it. Because of the inverted y coordinate in metal, we need to place the origin of the drawing with the appropriate offset that depends on the title height, even if we invert the y coordinate to match java2d coordinate system. I am just not sure that this is the only place where the insets might be changed. We need to add a "callback" which will be called every time the insets will be changed. Probably in the MTLLayer.replaceSurfaceData which should be called from the LWWindowsPeer#notifyReshape->replaceSurfaceData(). Currently, we skip that call if insets were changed. and this is why this bug arise. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From serb at openjdk.java.net Wed Apr 7 00:40:29 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 00:40:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8255800: Raster creation methods need some specification clean up [v3] In-Reply-To: <-_OCU44Hmti3PnpHsVOGVlJJl3tTNP46r0UTe_-SB9w=.ea3f5332-7dce-4a56-8fb1-6bae1285b033@github.com> References: <-_OCU44Hmti3PnpHsVOGVlJJl3tTNP46r0UTe_-SB9w=.ea3f5332-7dce-4a56-8fb1-6bae1285b033@github.com> Message-ID: On Fri, 2 Apr 2021 22:40:53 GMT, Phil Race wrote: >> https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but >> it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. >> I've spent a lot of time on what is just small number of factory methods in Raster because there are so >> many possible exceptions and in some cases they rely on other API they call to generate exceptions and >> these may have not been documented or documented acc. to some long lost behavior. >> I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that >> ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about >> always has to be an internal bug ! >> >> The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of >> cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 >> So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException >> to IllegalArgumentException. >> JCK conformance tests still pass so they must not test those conditions. > > Phil Race has updated the pull request incrementally with one additional commit since the last revision: > > 8255800: Raster creation methods need some specification clean up Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From serb at openjdk.java.net Wed Apr 7 00:41:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 00:41:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 20:38:57 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. >> >> The old print services should be invalidated. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Add a blank line to separate condition from body Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From serb at openjdk.java.net Wed Apr 7 02:58:31 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 02:58:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction In-Reply-To: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: On Tue, 6 Apr 2021 14:12:55 GMT, Ajit Ghaisas wrote: > Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I was cleaning up. src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 149: > 147: try { > 148: // getMTLConfigInfo() creates new MTLContext, so we should first > 149: // invalidate the current Java-level context and flush the queue... The old discussion was related not only to the comment but to the invalidateCurrentContext, do we need to do it? src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 152: > 150: NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; > 151: > 152: Please also check how this function is called, looks like previously it was called as a selector+an array as a parameter, and then reworked as a performOnMainThreadWaiting+block, but it still use an array as a parameter. I think it is similar to JDK-8238075. ------------- PR: https://git.openjdk.java.net/jdk/pull/3357 From serb at openjdk.java.net Wed Apr 7 02:59:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 02:59:23 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS In-Reply-To: References: <9-0Gtuwqcg22dWmmXwr6eSOF_hSxEpA3J-F4Mc-rdYY=.12820f83-bf7e-453f-a262-da82c7001087@github.com> Message-ID: On Fri, 19 Mar 2021 16:46:32 GMT, Alexey Ushakov wrote: >> Implementation for Metal pipeline has been added. >> >> I've also updated the test case to check rendering into different types of images, including VolatileImage. The test will fail now, if corresponding OpenGL (or Metal, if it's explicitly enabled) implementation part would be rolled back. > > Looks good! It looks fine to me. I will run the tests in CI just in case. ------------- PR: https://git.openjdk.java.net/jdk/pull/3007 From jdv at openjdk.java.net Wed Apr 7 04:06:32 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Wed, 7 Apr 2021 04:06:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: Message-ID: On Tue, 6 Apr 2021 20:38:57 GMT, Alexey Ivanov wrote: >> When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. >> >> The old print services should be invalidated. > > Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision: > > Add a blank line to separate condition from body Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From psadhukhan at openjdk.java.net Wed Apr 7 04:15:01 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 04:15:01 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Tue, 6 Apr 2021 20:39:04 GMT, Alexey Ivanov wrote: >> I added a blank line between the condition and the body. >> Does it look good? @mrserb, @jayathirthrao > > [Code Conventions for Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) say, ?Line wrapping for `if` statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult.? (It's the second to last block on the page.) If we are adding a new line, then I think we should need to add at l129, l138 otherwise it will look odd doing it at one place only. ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From dkonoplev at openjdk.java.net Wed Apr 7 05:27:56 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Wed, 7 Apr 2021 05:27:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 Message-ID: There was no code to check num of work items in compute shader. Also, I've replaced four similar shaders. ------------- Commit messages: - 8264143: Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 Changes: https://git.openjdk.java.net/jdk/pull/3368/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3368&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264143 Stats: 73 lines in 3 files changed: 29 ins; 26 del; 18 mod Patch: https://git.openjdk.java.net/jdk/pull/3368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3368/head:pull/3368 PR: https://git.openjdk.java.net/jdk/pull/3368 From dkonoplev at openjdk.java.net Wed Apr 7 05:31:43 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Wed, 7 Apr 2021 05:31:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 Message-ID: Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. It's safe since we copy tile from the image with memcpy. // copy src pixels inside src bounds to buff for (int row = 0; row < sh; row++) { memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); raster += (NSUInteger)srcInfo->scanStride; } ------------- Commit messages: - 8264318: DrawHugeImageTest.java fails on apple M1 Changes: https://git.openjdk.java.net/jdk/pull/3369/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3369&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264318 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3369.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3369/head:pull/3369 PR: https://git.openjdk.java.net/jdk/pull/3369 From github.com+76791+alblue at openjdk.java.net Wed Apr 7 06:18:37 2021 From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt) Date: Wed, 7 Apr 2021 06:18:37 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264680: Use the blessed modifier order in java.desktop In-Reply-To: References: Message-ID: On Sat, 3 Apr 2021 22:03:44 GMT, Alex Blewitt wrote: > 8264680: Use the blessed modifier order in java.desktop This pull request has now been integrated. Changeset: 92fad1b4 Author: Alex Blewitt Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/92fad1b4 Stats: 132 lines in 11 files changed: 0 ins; 114 del; 18 mod 8264680: Use the blessed modifier order in java.desktop Reviewed-by: serb, kizune, azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3337 From github.com+741251+turbanoff at openjdk.java.net Wed Apr 7 06:39:51 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 7 Apr 2021 06:39:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: <3cbmasQ5AlXcT2qoxYxlAUP_gtPwPsiA6bCT7qkOclw=.d33c2593-591c-420e-8375-4524475f4927@github.com> On Tue, 30 Mar 2021 15:46:56 GMT, Alexander Zvegintsev wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop >> >> fix copyright year > > src/java.desktop/windows/classes/sun/java2d/d3d/D3DContext.java line 139: > >> 137: @Override >> 138: public String toString() { >> 139: StringBuilder buf = new StringBuilder(super.toString()); > > Looks like this is the only file where copyright year is not updated. Thanks. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From github.com+741251+turbanoff at openjdk.java.net Wed Apr 7 06:39:48 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Wed, 7 Apr 2021 06:39:48 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop fix copyright year ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/80bff1db..963dc56e Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251 From dkonoplev at openjdk.java.net Wed Apr 7 07:38:45 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Wed, 7 Apr 2021 07:38:45 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 [v2] In-Reply-To: References: Message-ID: <5f3kZyateKDDIN_096ywxeKMM8SrOwj3g1IFfROzgN4=.33df7853-55b5-4f57-b5ff-43414d6a4788@github.com> > There was no code to check num of work items in compute shader. > Also, I've replaced four similar shaders. Denis Konoplev has updated the pull request incrementally with one additional commit since the last revision: 8264143: Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 Add stdint include to fix x64 build ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3368/files - new: https://git.openjdk.java.net/jdk/pull/3368/files/40760c12..51eaa139 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3368&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3368&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3368/head:pull/3368 PR: https://git.openjdk.java.net/jdk/pull/3368 From aivanov at openjdk.java.net Wed Apr 7 10:52:29 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 10:52:29 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> Message-ID: On Wed, 7 Apr 2021 04:12:55 GMT, Prasanta Sadhukhan wrote: >> [Code Conventions for Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) say, ?Line wrapping for `if` statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult.? (It's the second to last block on the page.) > > If we are adding a new line, then I think we should need to add at l129, l138 otherwise it will look odd doing it at one place only. I haven't touched that code at all. Not that odd because it's isolated to the new function now. What is your suggestion? Refactor all if statements in these two functions? Submit a separate bug for refactor all if statements the entire file? Revert back to no new line, leaving this particular if untouched as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From azvegint at openjdk.java.net Wed Apr 7 11:01:36 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 7 Apr 2021 11:01:36 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: <3G3a1TvBD_pa6-QmuKRm6HKbMDNCkCvjEyA1SqkOd3s=.478017e6-57ad-4823-ac39-8324f7a2ef5a@github.com> On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop > > fix copyright year Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From prasanta.sadhukhan at oracle.com Wed Apr 7 11:25:56 2021 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 7 Apr 2021 11:25:56 +0000 Subject: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] In-Reply-To: References: <639QYPzkO-ADNB2QfuzijVlNIpOM50pfYgpv3M8xy_4=.e190ac4d-0289-435a-b7c5-ae2a8b72a397@github.com> , Message-ID: I have not looked at entire file but since this function was modified, I made that suggestion. I am not that particular if you wish to ignore that. Regards Prasanta Get Outlook for Android ________________________________ From: 2d-dev <2d-dev-retn at openjdk.java.net> on behalf of Alexey Ivanov Sent: Wednesday, April 7, 2021 4:22:29 PM To: 2d-dev at openjdk.java.net <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] RFR: 8263984: Invalidate printServices when there are no printers [v3] On Wed, 7 Apr 2021 04:12:55 GMT, Prasanta Sadhukhan wrote: >> [Code Conventions for Java](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#248) say, ?Line wrapping for `if` statements should generally use the 8-space rule, since conventional (4 space) indentation makes seeing the body difficult.? (It's the second to last block on the page.) > > If we are adding a new line, then I think we should need to add at l129, l138 otherwise it will look odd doing it at one place only. I haven't touched that code at all. Not that odd because it's isolated to the new function now. What is your suggestion? Refactor all if statements in these two functions? Submit a separate bug for refactor all if statements the entire file? Revert back to no new line, leaving this particular if untouched as well? ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 -------------- next part -------------- An HTML attachment was scrubbed... URL: From prr at openjdk.java.net Wed Apr 7 14:53:37 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 7 Apr 2021 14:53:37 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8255800: Raster creation methods need some specification clean up In-Reply-To: References: Message-ID: On Fri, 26 Mar 2021 19:53:44 GMT, Phil Race wrote: > https://bugs.openjdk.java.net/browse/JDK-8255800 could have been a one line spec clean up but > it didn't take a lot of looking to realize there were many more inconsistencies between spec and implementation. > I've spent a lot of time on what is just small number of factory methods in Raster because there are so > many possible exceptions and in some cases they rely on other API they call to generate exceptions and > these may have not been documented or documented acc. to some long lost behavior. > I've mostly tried to ONLY change spec. But I couldn't help myself when some checks were missed that > ended up with bizarre and dubious behavior - throwing NegativeArrayIndexException which just about > always has to be an internal bug ! > > The supplied test passes on JDK 16 as well as this code, because the (relatively) small number of > cases where JDK 16 threw NegativeArrayIndexException are caught and allowed only for releases < 17 > So where you see those in the test it corresponds to the behavioral changes from NegativeArrayIndexException > to IllegalArgumentException. > JCK conformance tests still pass so they must not test those conditions. This pull request has now been integrated. Changeset: adb860ec Author: Phil Race URL: https://git.openjdk.java.net/jdk/commit/adb860ec Stats: 1494 lines in 5 files changed: 1424 ins; 35 del; 35 mod 8255800: Raster creation methods need some specification clean up Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3223 From aivanov at openjdk.java.net Wed Apr 7 15:30:40 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 15:30:40 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: On Wed, 7 Apr 2021 06:39:48 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop > > fix copyright year Marked as reviewed by aivanov (Reviewer). src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88: > 86: while (eIter.hasNext()) { > 87: Map.Entry entry = eIter.next(); > 88: buf.append(entry.getKey()).append(": ").append(entry.getValue()).append("\n"); Would it be clearer if each append was on its own line? Suggestion: buf.append(entry.getKey()) .append(": ") .append(entry.getValue()) .append("\n"); ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Wed Apr 7 15:34:03 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Wed, 7 Apr 2021 15:34:03 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8263984: Invalidate printServices when there are no printers In-Reply-To: References: Message-ID: On Tue, 23 Mar 2021 13:45:33 GMT, Alexey Ivanov wrote: > When `getAllPrinterNames()` returns null, the list of `printServices` is assigned a new empty array without invalidating old services which were in the array before. > > The old print services should be invalidated. This pull request has now been integrated. Changeset: 9d650397 Author: Alexey Ivanov URL: https://git.openjdk.java.net/jdk/commit/9d650397 Stats: 8 lines in 1 file changed: 7 ins; 1 del; 0 mod 8263984: Invalidate printServices when there are no printers Reviewed-by: serb, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3151 From dkonoplev at openjdk.java.net Wed Apr 7 19:00:17 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Wed, 7 Apr 2021 19:00:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 [v3] In-Reply-To: References: Message-ID: > There was no code to check num of work items in compute shader. > Also, I've replaced four similar shaders. Denis Konoplev has updated the pull request incrementally with one additional commit since the last revision: 8264143: Change uint8_t to unsigned char ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3368/files - new: https://git.openjdk.java.net/jdk/pull/3368/files/51eaa139..8cc9463d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3368&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3368&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3368.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3368/head:pull/3368 PR: https://git.openjdk.java.net/jdk/pull/3368 From serb at openjdk.java.net Wed Apr 7 19:55:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 19:55:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse Math.multiplyExact/addExact in the LCMSImageLayout class Message-ID: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions. - Cleanup: the usage of do/while(false) is removed ------------- Commit messages: - delete "do{...} while (false);" - safeXX -> xxExact Changes: https://git.openjdk.java.net/jdk/pull/3333/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3333&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264666 Stats: 110 lines in 1 file changed: 5 ins; 36 del; 69 mod Patch: https://git.openjdk.java.net/jdk/pull/3333.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3333/head:pull/3333 PR: https://git.openjdk.java.net/jdk/pull/3333 From serb at openjdk.java.net Wed Apr 7 19:56:01 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 19:56:01 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse Math.multiplyExact/addExact in the LCMSImageLayout class In-Reply-To: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> Message-ID: On Fri, 2 Apr 2021 23:02:50 GMT, Sergey Bylokhov wrote: > - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions. > - Cleanup: the usage of do/while(false) is removed The nice PR number: 3333! src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java line 241: > 239: l.imageAtOnce = true; > 240: } > 241: } while (false); Any idea why the "do/while(false)" was used here? ------------- PR: https://git.openjdk.java.net/jdk/pull/3333 From serb at openjdk.java.net Wed Apr 7 19:59:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 19:59:38 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: Message-ID: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { > memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); > raster += (NSUInteger)srcInfo->scanStride; > } I wonder why we have two similar but different constants: #define MaxTextureSize 16384 #define MTL_GPU_FAMILY_MAC_TXT_SIZE 16384 src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 162: > 160: const int sh = MIN(srcInfo->bounds.y2 - srcInfo->bounds.y1, MTL_GPU_FAMILY_MAC_TXT_SIZE); > 161: const int dw = MIN(dx2 - dx1, MTL_GPU_FAMILY_MAC_TXT_SIZE); > 162: const int dh = MIN(dy2 - dy1, MTL_GPU_FAMILY_MAC_TXT_SIZE); Just curious why such big coordinates are passed here. We should not be able to create a window of such size, as well as a volatile image. ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From prr at openjdk.java.net Wed Apr 7 20:17:36 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 7 Apr 2021 20:17:36 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse Math.multiplyExact/addExact in the LCMSImageLayout class In-Reply-To: References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> Message-ID: On Fri, 2 Apr 2021 23:06:43 GMT, Sergey Bylokhov wrote: >> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions. >> - Cleanup: the usage of do/while(false) is removed > > The nice PR number: 3333! I don't understand the exception handling here. multiplyExact and addExact will throw a runtime exception - ArithmeticException. And I don't see where it is caught. The change for ImageLayoutException to extend ArithmeticException doesn't seem like it can help here. Where is the ArithmeticException being turned into ImageLayoutException ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3333 From avu at openjdk.java.net Wed Apr 7 20:34:41 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 7 Apr 2021 20:34:41 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Tue, 6 Apr 2021 12:51:47 GMT, Alexey Ushakov wrote: >>> Is it possible to automatically test it? >> >> Yes, just added the test. > >> @avu Test passes without fix also. > @jayathirthrao Could you provide the details about your configuration along with parameters passed to jtreg ? > @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel Iris Graphics 6100. > jtreg command i am using "jtreg -jdk: -Dsun.java2d.metal=true " @jayathirthrao I'm not sure that -Dsun.java2d.metal had been passed to the test JVM. I rechecked with slightly different command line and the test fails without the fix jtreg -ignore:quiet -v -a -xml -vmoptions:"-Dsun.java2d.metal=True " -testjdk:path_to_jdk path_to_test ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From azvegint at openjdk.java.net Wed Apr 7 21:51:41 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Wed, 7 Apr 2021 21:51:41 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse Math.multiplyExact/addExact in the LCMSImageLayout class In-Reply-To: References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> Message-ID: On Sun, 4 Apr 2021 07:58:44 GMT, Sergey Bylokhov wrote: >> - The hand-crafted methods for addition and multiplication are replaced by the "Math" versions. >> - Cleanup: the usage of do/while(false) is removed > > src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSImageLayout.java line 241: > >> 239: l.imageAtOnce = true; >> 240: } >> 241: } while (false); > > Any idea why the "do/while(false)" was used here? Probably it is just a way to highlight and improve readability of a block of code, but simply `{}` would be enough in this case. ------------- PR: https://git.openjdk.java.net/jdk/pull/3333 From avu at openjdk.java.net Wed Apr 7 22:58:31 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 7 Apr 2021 22:58:31 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] [v4] In-Reply-To: References: Message-ID: > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8258788: incorrect response to change in window insets [lanai] Perform replaceSurfaceData on insets change ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3308/files - new: https://git.openjdk.java.net/jdk/pull/3308/files/52fc75e7..ed5e6814 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3308&range=02-03 Stats: 35 lines in 8 files changed: 17 ins; 17 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3308.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3308/head:pull/3308 PR: https://git.openjdk.java.net/jdk/pull/3308 From avu at openjdk.java.net Wed Apr 7 23:05:14 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 7 Apr 2021 23:05:14 GMT Subject: [OpenJDK 2D-Dev] Withdrawn: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: Message-ID: On Thu, 1 Apr 2021 14:38:52 GMT, Alexey Ushakov wrote: > Dynamically change MTLLayer insets depending on FULL_WINDOW_CONTENT property. MTLLayer.h header cleanup. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From serb at openjdk.java.net Wed Apr 7 23:27:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 7 Apr 2021 23:27:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264666: Reuse Math.multiplyExact/addExact in the LCMSImageLayout class In-Reply-To: References: <3iYQc9duUeEGRqm3146n4XhLQ_LY6YzXv-f-WgDu9sE=.a0a36297-4ce8-489c-9b50-43aede408e3b@github.com> Message-ID: <_Pp7mfjhHPkm5vt8Hx0sTX6Hq7Aenn-IFXiPWFfIODU=.4a353af4-21da-44c8-96e2-42c0cd75555a@github.com> On Wed, 7 Apr 2021 20:14:06 GMT, Phil Race wrote: > I don't understand the exception handling here. multiplyExact and addExact will throw a runtime exception - ArithmeticException. And I don't see where it is caught. The change for ImageLayoutException to extend ArithmeticException doesn't seem like it can help here. Where is the ArithmeticException being turned into ImageLayoutException ? O_o for some reason... missed that. ------------- PR: https://git.openjdk.java.net/jdk/pull/3333 From serb at openjdk.java.net Thu Apr 8 00:52:08 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Thu, 8 Apr 2021 00:52:08 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> References: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> Message-ID: <7cNsqYIflcvXR6O2u-OC1ISmgxYRYUP_Zx49qutJewU=.6d66b0af-f72f-461d-9b59-842e8796c8d5@github.com> On Wed, 7 Apr 2021 19:56:43 GMT, Sergey Bylokhov wrote: >> Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. >> >> It's safe since we copy tile from the image with memcpy. >> // copy src pixels inside src bounds to buff >> for (int row = 0; row < sh; row++) { >> memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); >> raster += (NSUInteger)srcInfo->scanStride; >> } > > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m line 162: > >> 160: const int sh = MIN(srcInfo->bounds.y2 - srcInfo->bounds.y1, MTL_GPU_FAMILY_MAC_TXT_SIZE); >> 161: const int dw = MIN(dx2 - dx1, MTL_GPU_FAMILY_MAC_TXT_SIZE); >> 162: const int dh = MIN(dy2 - dy1, MTL_GPU_FAMILY_MAC_TXT_SIZE); > > Just curious why such big coordinates are passed here. We should not be able to create a window of such size, as well as a volatile image. Missed the MIN usage, initially read it as max. ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From aghaisas at openjdk.java.net Thu Apr 8 10:48:37 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 8 Apr 2021 10:48:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v2] In-Reply-To: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: <8ZtlMUIBPM_cxuVXrWK_FSLeSKnV0t4VF-4emN0r_Ow=.2a674758-2e02-4f4d-b335-70d6eaa385c3@github.com> > Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I was cleaning up. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: Review fixes ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/ade2381d..36ed087b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=00-01 Stats: 128 lines in 1 file changed: 20 ins; 81 del; 27 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357 From aghaisas at openjdk.java.net Thu Apr 8 10:48:38 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 8 Apr 2021 10:48:38 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v2] In-Reply-To: References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: On Wed, 7 Apr 2021 02:50:03 GMT, Sergey Bylokhov wrote: >> Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: >> >> Review fixes > > src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 149: > >> 147: try { >> 148: // getMTLConfigInfo() creates new MTLContext, so we should first >> 149: // invalidate the current Java-level context and flush the queue... > > The old discussion was related not only to the comment but to the invalidateCurrentContext, do we need to do it? This is the only place where we use MTLContext.invalidateCurrentContext() - which when processed in MTLRenderQueue - clears some native stuff and nulls out both mtlc and dstOps pointers maintained in MTLRenderQueue.m. I think, this will be important once we get rid of SET_SCRATCH_SURFACE under JDK-8263309. > src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLGraphicsConfig.m line 152: > >> 150: NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; >> 151: >> 152: > > Please also check how this function is called, looks like previously it was called as a selector+an array as a parameter, and then reworked as a performOnMainThreadWaiting+block, but it still use an array as a parameter. I think it is similar to JDK-8238075. Excellent point! Thanks for the pointer to the bug. A lot of code in this file can be cleaned up. I will update the PR soon. ------------- PR: https://git.openjdk.java.net/jdk/pull/3357 From aghaisas at openjdk.java.net Thu Apr 8 10:51:52 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Thu, 8 Apr 2021 10:51:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v3] In-Reply-To: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: <0AbU6QHzfNURm8Urgj2NMCS-k1i6wrYdAYIBIcrrnL0=.1c7ae0d2-9f36-4e68-bc5a-03ee15902b95@github.com> > Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I was cleaning up. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: log message correction ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/36ed087b..45e7aec0 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357 From shade at openjdk.java.net Thu Apr 8 13:09:40 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 8 Apr 2021 13:09:40 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo Message-ID: Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 ------------- Commit messages: - 8264923: PNGImageWriter.write_zTXt throws Exception with a typo Changes: https://git.openjdk.java.net/jdk/pull/3397/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3397&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264923 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3397.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3397/head:pull/3397 PR: https://git.openjdk.java.net/jdk/pull/3397 From aivanov at openjdk.java.net Thu Apr 8 13:47:21 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 8 Apr 2021 13:47:21 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From jdv at openjdk.java.net Thu Apr 8 14:00:26 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 8 Apr 2021 14:00:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: <7LIAqaC0ToIlW4kJZ_LGffGbQZ96BS4JRgKSela-M8c=.4c75c7ae-6f0f-48f4-a1b2-a9ec853846ce@github.com> On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 14:43:50 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 14:43:50 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent place each 'append' call on its own line ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3251/files - new: https://git.openjdk.java.net/jdk/pull/3251/files/963dc56e..d083f953 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3251&range=02-03 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3251.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3251/head:pull/3251 PR: https://git.openjdk.java.net/jdk/pull/3251 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 14:43:52 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 14:43:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v3] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> <8GAS4aHM0frtXpSG96f9tJczhTFPFPV_b9gWhFUJ8FY=.caacc6fa-6b9d-42f0-834b-ad1b210834be@github.com> Message-ID: On Wed, 7 Apr 2021 15:21:40 GMT, Alexey Ivanov wrote: >> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: >> >> [PATCH] Replace uses of StringBuffer with StringBuilder in java.desktop >> >> fix copyright year > > src/java.desktop/unix/classes/sun/awt/X11/XCreateWindowParams.java line 88: > >> 86: while (eIter.hasNext()) { >> 87: Map.Entry entry = eIter.next(); >> 88: buf.append(entry.getKey()).append(": ").append(entry.getValue()).append("\n"); > > Would it be clearer if each append was on its own line? > Suggestion: > > buf.append(entry.getKey()) > .append(": ") > .append(entry.getValue()) > .append("\n"); done ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From aivanov at openjdk.java.net Thu Apr 8 14:51:07 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Thu, 8 Apr 2021 14:51:07 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by aivanov (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From avu at openjdk.java.net Thu Apr 8 14:58:20 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Thu, 8 Apr 2021 14:58:20 GMT Subject: [OpenJDK 2D-Dev] RFR: 8258788: incorrect response to change in window insets [lanai] In-Reply-To: References: <3iUS9YjVDKfqUj7yYKkW9d-teU8D4Ve9J4_5Y0nw2Fk=.db2f9912-0aa2-409d-9b6e-20c14138d62c@github.com> Message-ID: On Wed, 7 Apr 2021 20:29:12 GMT, Alexey Ushakov wrote: >>> @avu Test passes without fix also. >> @jayathirthrao Could you provide the details about your configuration along with parameters passed to jtreg ? > >> @avu I am running test in 13 inch Macbook Early 2015 with integrated Intel Iris Graphics 6100. >> jtreg command i am using "jtreg -jdk: -Dsun.java2d.metal=true " > @jayathirthrao I'm not sure that -Dsun.java2d.metal had been passed to the test JVM. I rechecked with slightly different command line and the test fails without the fix > jtreg -ignore:quiet -v -a -xml -vmoptions:"-Dsun.java2d.metal=True " -testjdk:path_to_jdk path_to_test I've created a simpler solution within another pull request. Please, have a look https://git.openjdk.java.net/jdk/pull/3390 ------------- PR: https://git.openjdk.java.net/jdk/pull/3308 From azvegint at openjdk.java.net Thu Apr 8 15:26:18 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 8 Apr 2021 15:26:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264428: Cleanup usages of StringBuffer in java.desktop [v4] In-Reply-To: References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Thu, 8 Apr 2021 14:43:50 GMT, Andrey Turbanov wrote: >> There are few possible cleanups in java.desktop related to legacy StringBuffer usages: >> 1. In few places StringBuffer can be replaced with plain String concatenation. >> 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. >> 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. >> 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. > > Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision: > > 8264484: Replace uses of StringBuffer with StringBuilder in jdk.hotspot.agent > > place each 'append' call on its own line Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From dkonoplev at openjdk.java.net Thu Apr 8 16:48:11 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Thu, 8 Apr 2021 16:48:11 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> References: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> Message-ID: On Wed, 7 Apr 2021 19:54:03 GMT, Sergey Bylokhov wrote: > I wonder why we have two similar but different constants: > #define MaxTextureSize 16384 > #define MTL_GPU_FAMILY_MAC_TXT_SIZE 16384 I can remove MaxTextureSize and replace its usages. Should I file a new bug or put changes in this PR? ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From azvegint at openjdk.java.net Thu Apr 8 16:51:10 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 8 Apr 2021 16:51:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From kizune at openjdk.java.net Thu Apr 8 16:59:15 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 8 Apr 2021 16:59:15 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 Marked as reviewed by kizune (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From github.com+741251+turbanoff at openjdk.java.net Thu Apr 8 21:27:14 2021 From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov) Date: Thu, 8 Apr 2021 21:27:14 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264428: Cleanup usages of StringBuffer in java.desktop In-Reply-To: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> References: <2y9jvm8hnBRZQIO4qwAY-C07aSQM1QIzIT6SWAj7c70=.bda3ef0d-a445-40b0-b155-3920d072cb89@github.com> Message-ID: On Mon, 29 Mar 2021 20:50:14 GMT, Andrey Turbanov wrote: > There are few possible cleanups in java.desktop related to legacy StringBuffer usages: > 1. In few places StringBuffer can be replaced with plain String concatenation. > 2. StringBuffer can be replaced with StringBuilder. StringBuilder has better performance as it is not thread-safe. > 3. There are few places where result of string concatenation is passed to StringBuffer.append method. Using separate `.append` calls is more clear. > 4. In few places primitives are unnecessary converted to String before `.append` call. They can be replaced with specialized methods (like `.append(int)` calls. This pull request has now been integrated. Changeset: 8a235807 Author: Andrey Turbanov Committer: Alexander Zvegintsev URL: https://git.openjdk.java.net/jdk/commit/8a235807 Stats: 48 lines in 11 files changed: 3 ins; 8 del; 37 mod 8264428: Cleanup usages of StringBuffer in java.desktop Reviewed-by: azvegint, aivanov ------------- PR: https://git.openjdk.java.net/jdk/pull/3251 From shade at openjdk.java.net Fri Apr 9 06:28:20 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:28:20 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 16:55:49 GMT, Alexander Zuev wrote: >> Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: >> https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 > > Marked as reviewed by kizune (Reviewer). Whoa, so many reviews, thanks! :) ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From shade at openjdk.java.net Fri Apr 9 06:28:21 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Fri, 9 Apr 2021 06:28:21 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264923: PNGImageWriter.write_zTXt throws Exception with a typo In-Reply-To: References: Message-ID: On Thu, 8 Apr 2021 13:00:49 GMT, Aleksey Shipilev wrote: > Noticed this when backporting JDK-8242557: there is a trivial copy-paste error in exception message. See: > https://hg.openjdk.java.net/jdk/jdk/rev/645c71334acd#l1.58 This pull request has now been integrated. Changeset: 051c117b Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/051c117b Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8264923: PNGImageWriter.write_zTXt throws Exception with a typo Reviewed-by: aivanov, jdv, azvegint, kizune ------------- PR: https://git.openjdk.java.net/jdk/pull/3397 From serb at openjdk.java.net Fri Apr 9 07:25:18 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 9 Apr 2021 07:25:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v3] In-Reply-To: References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: <1WDZ9bDY7yGTjiXqWN0RlHTH0ktjTlG42L8z4B1zPo8=.86125794-9f0d-46c1-abd7-713f75146a54@github.com> On Thu, 8 Apr 2021 10:39:38 GMT, Ajit Ghaisas wrote: >> src/java.desktop/macosx/classes/sun/java2d/metal/MTLGraphicsConfig.java line 149: >> >>> 147: try { >>> 148: // getMTLConfigInfo() creates new MTLContext, so we should first >>> 149: // invalidate the current Java-level context and flush the queue... >> >> The old discussion was related not only to the comment but to the invalidateCurrentContext, do we need to do it? > > This is the only place where we use MTLContext.invalidateCurrentContext() - which when processed in MTLRenderQueue - clears some native stuff and nulls out both mtlc and dstOps pointers maintained in MTLRenderQueue.m. I think, this will be important once we get rid of SET_SCRATCH_SURFACE under JDK-8263309. But why you need to invalidate context here? Why do you need "clears some native stuff and nulls out both mtlc and dstOps pointers maintained in MTLRenderQueue.m"? In OGL the getCGLConfigInfo() change the state of the OGL state due to "makeCurrentContext", this is why we need to update the lava level state to "invalid", otherwise we will get a mismatch between the state in the native and java state. ------------- PR: https://git.openjdk.java.net/jdk/pull/3357 From serb at openjdk.java.net Sat Apr 10 20:34:30 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 10 Apr 2021 20:34:30 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> Message-ID: On Thu, 8 Apr 2021 16:45:23 GMT, Denis Konoplev wrote: > I can remove MaxTextureSize and replace its usages. > Should I file a new bug or put changes in this PR? Yes please file a bug. ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From dkonoplev at openjdk.java.net Mon Apr 12 10:47:33 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Mon, 12 Apr 2021 10:47:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: Message-ID: <5x8OAa9Qy1VrZK7rWcQkaCn8T8jz7ItDQZEsc-88RPU=.afbfdd78-cc36-4e2c-b9d9-871761fd11c9@github.com> On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { > memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); > raster += (NSUInteger)srcInfo->scanStride; > } Bug: [Remove duplication constant MaxTextureSize](https://bugs.openjdk.java.net/browse/JDK-8265062) ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From dkonoplev at openjdk.java.net Mon Apr 12 13:55:33 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Mon, 12 Apr 2021 13:55:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: <9d-iOVkF4-Z4cRZ8K5Rje9fy_t7BcKw5JUI-NA5N84E=.c72c57a3-65cd-4f08-94f1-492a4c2055b3@github.com> Message-ID: On Sat, 10 Apr 2021 20:31:31 GMT, Sergey Bylokhov wrote: >>> I wonder why we have two similar but different constants: >>> #define MaxTextureSize 16384 >>> #define MTL_GPU_FAMILY_MAC_TXT_SIZE 16384 >> >> I can remove MaxTextureSize and replace its usages. >> Should I file a new bug or put changes in this PR? > >> I can remove MaxTextureSize and replace its usages. >> Should I file a new bug or put changes in this PR? > > Yes please file a bug. @mrserb maybe you know someone who can review my PR: [3368](https://github.com/openjdk/jdk/pull/3368) ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From serb at openjdk.java.net Tue Apr 13 20:15:59 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Tue, 13 Apr 2021 20:15:59 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS [v2] In-Reply-To: <3q5Im_Hh45tOK9VTt5A2nrRxvgHFB_j3wfsBQlq_jgg=.5ec0eced-845e-4883-bc08-539209ece792@github.com> References: <3q5Im_Hh45tOK9VTt5A2nrRxvgHFB_j3wfsBQlq_jgg=.5ec0eced-845e-4883-bc08-539209ece792@github.com> Message-ID: On Fri, 19 Mar 2021 13:48:12 GMT, Dmitry Batrak wrote: >> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem, >> found while preparing the pull request, fixed. >> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s >> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes. >> Notable implementation details are listed below. >> >> **Glyph image generation** >> >> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis, >> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized' >> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they >> are not scaled proportionally with font size (as they do for vector fonts). >> >> **Glyph image storage** >> >> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes >> of storage per pixel. Color components are stored in pre-multiplied alpha format. >> >> **Glyph rendering** >> >> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the >> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with >> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting), >> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on >> specific segments of GlyphList. >> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed >> (most text renderers don't need this information). >> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer, >> and by re-using existing Blit primitive in off-screen renderers. >> >> **Testing** >> >> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is >> rendered for the emoji character, when painting to BufferedImage. >> >> Existing tests pass after the change. > > Dmitry Batrak has updated the pull request incrementally with two additional commits since the last revision: > > - 8263583: Emoji rendering on macOS > > extended test case to cover different types of target surfaces > - 8263583: Emoji rendering on macOS > > implementation for Metal rendering pipeline Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3007 From serb at openjdk.java.net Wed Apr 14 21:34:38 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 14 Apr 2021 21:34:38 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { > memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); > raster += (NSUInteger)srcInfo->scanStride; > } Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From jdv at openjdk.java.net Thu Apr 15 08:43:33 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 15 Apr 2021 08:43:33 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { > memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); > raster += (NSUInteger)srcInfo->scanStride; > } Marked as reviewed by jdv (Reviewer). I will sponsor this PR, waiting for complete test run to finish. ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From dkonoplev at openjdk.java.net Thu Apr 15 13:53:36 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Thu, 15 Apr 2021 13:53:36 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264318 Lanai: DrawHugeImageTest.java fails on apple M1 In-Reply-To: References: Message-ID: <7FZzs4wnTW5GitMLU_KEGx_upydWcOOEnwqA1RL_Q9I=.69c8f42b-401b-4ad8-8088-f15798e102ac@github.com> On Wed, 7 Apr 2021 05:24:30 GMT, Denis Konoplev wrote: > Check if blit sizes are less than MTL_GPU_FAMILY_MAC_TXT_SIZE. > > It's safe since we copy tile from the image with memcpy. > > // copy src pixels inside src bounds to buff > for (int row = 0; row < sh; row++) { > memcpy(buff.contents + (row * sw * srcInfo->pixelStride), raster, sw * srcInfo->pixelStride); > raster += (NSUInteger)srcInfo->scanStride; > } This pull request has now been integrated. Changeset: 0fee6eca Author: Denis Konoplev Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/0fee6eca Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod 8264318: Lanai: DrawHugeImageTest.java fails on apple M1 Reviewed-by: serb, jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3369 From dkonoplev at openjdk.java.net Thu Apr 15 14:48:43 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Thu, 15 Apr 2021 14:48:43 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265062: Remove duplication constant MaxTextureSize Message-ID: I've removed MaxTextureSize and replaced its usages with MTL_GPU_FAMILY_MAC_TXT_SIZE ------------- Commit messages: - 8265062: Remove duplication constant MaxTextureSize Changes: https://git.openjdk.java.net/jdk/pull/3519/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3519&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265062 Stats: 10 lines in 3 files changed: 0 ins; 6 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3519.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3519/head:pull/3519 PR: https://git.openjdk.java.net/jdk/pull/3519 From aghaisas at openjdk.java.net Fri Apr 16 06:02:40 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Fri, 16 Apr 2021 06:02:40 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS Message-ID: This PR makes Metal as the default Java2D rendering pipeline for macOS. Note : from JBS description : The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). ------------- Commit messages: - 8265304 - make metal pipeline default Changes: https://git.openjdk.java.net/jdk/pull/3534/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3534&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265304 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jdk/pull/3534.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3534/head:pull/3534 PR: https://git.openjdk.java.net/jdk/pull/3534 From jdv at openjdk.java.net Fri Apr 16 06:19:37 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Fri, 16 Apr 2021 06:19:37 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. > We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). LGTM. Please make sure CI test run is fine before integration. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3534 From jdv at openjdk.java.net Fri Apr 16 13:22:35 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Fri, 16 Apr 2021 13:22:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 [v3] In-Reply-To: References: Message-ID: <2gaJ9rMPg4Dn_B3wA4ijoSXgNpRJVMDxvufU6z15Kak=.ce6bdd0e-fdfc-4522-a1e7-5e225171621a@github.com> On Wed, 7 Apr 2021 19:00:17 GMT, Denis Konoplev wrote: >> There was no code to check num of work items in compute shader. >> Also, I've replaced four similar shaders. > > Denis Konoplev has updated the pull request incrementally with one additional commit since the last revision: > > 8264143: Change uint8_t to unsigned char LGTM. Ran RenderPerfTest in my Intel Integrated SoC there are no issues. CI test run of jtreg and JCK tests is fine. Basic sanity with J2DDemo and Swingset2 is also fine. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3368 From kcr at openjdk.java.net Fri Apr 16 14:12:35 2021 From: kcr at openjdk.java.net (Kevin Rushforth) Date: Fri, 16 Apr 2021 14:12:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. > We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). Marked as reviewed by kcr (Author). ------------- PR: https://git.openjdk.java.net/jdk/pull/3534 From azvegint at openjdk.java.net Fri Apr 16 14:12:35 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Fri, 16 Apr 2021 14:12:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS In-Reply-To: References: Message-ID: <62wcsCsRV4K4oOgM8sEha6J_IfEaaSN65am9NgXsJ6Y=.01c5effd-cde4-4d0a-b6d2-608ed079a9e7@github.com> On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. > We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3534 From prr at openjdk.java.net Fri Apr 16 14:53:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 16 Apr 2021 14:53:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. > We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3534 From serb at openjdk.java.net Sat Apr 17 04:36:35 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sat, 17 Apr 2021 04:36:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265062: Remove duplication constant MaxTextureSize In-Reply-To: References: Message-ID: On Thu, 15 Apr 2021 14:42:55 GMT, Denis Konoplev wrote: > I've removed MaxTextureSize and replaced its usages with MTL_GPU_FAMILY_MAC_TXT_SIZE In a few places we have such pattern "sh = MIN(sh, MTL_GPU_FAMILY_MAC_TXT_SIZE);", in what cases we can use the data larger than MTL_GPU_FAMILY_MAC_TXT_SIZE since we should not create surfaces bigger than "MaxTextureSize"? ------------- PR: https://git.openjdk.java.net/jdk/pull/3519 From dkonoplev at openjdk.java.net Sat Apr 17 06:10:35 2021 From: dkonoplev at openjdk.java.net (Denis Konoplev) Date: Sat, 17 Apr 2021 06:10:35 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264143 Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 In-Reply-To: References: Message-ID: On Wed, 7 Apr 2021 05:20:18 GMT, Denis Konoplev wrote: > There was no code to check num of work items in compute shader. > Also, I've replaced four similar shaders. This pull request has now been integrated. Changeset: 926e3bc0 Author: Denis Konoplev Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/926e3bc0 Stats: 73 lines in 3 files changed: 29 ins; 26 del; 18 mod 8264143: Lanai: RenderPerfTest.BgrSwBlitImage has artefacts on apple M1 Reviewed-by: jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3368 From aghaisas at openjdk.java.net Sat Apr 17 12:36:35 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Sat, 17 Apr 2021 12:36:35 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS In-Reply-To: References: Message-ID: On Fri, 16 Apr 2021 05:57:13 GMT, Ajit Ghaisas wrote: > This PR makes Metal as the default Java2D rendering pipeline for macOS. > > Note : from JBS description : > The plan of record has always been that for JDK 17 the new Metal pipeline will be OFF by default and must be explicitly enabled by setting a system property. > We are not changing that plan but to get more testing exposure we intend to make it the default (instead of OpenGL) for approximately one month (from the next build up to the 20th May build of JDK 17). This pull request has now been integrated. Changeset: cb8394a8 Author: Ajit Ghaisas URL: https://git.openjdk.java.net/jdk/commit/cb8394a8 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod 8265304: Temporarily make Metal the default 2D rendering pipeline for macOS Reviewed-by: jdv, kcr, azvegint, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/3534 From dbatrak at openjdk.java.net Mon Apr 19 07:34:39 2021 From: dbatrak at openjdk.java.net (Dmitry Batrak) Date: Mon, 19 Apr 2021 07:34:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263583: Emoji rendering on macOS [v2] In-Reply-To: <3q5Im_Hh45tOK9VTt5A2nrRxvgHFB_j3wfsBQlq_jgg=.5ec0eced-845e-4883-bc08-539209ece792@github.com> References: <3q5Im_Hh45tOK9VTt5A2nrRxvgHFB_j3wfsBQlq_jgg=.5ec0eced-845e-4883-bc08-539209ece792@github.com> Message-ID: On Fri, 19 Mar 2021 13:48:12 GMT, Dmitry Batrak wrote: >> This is the implementation used by JetBrains Runtime for the last 4 years, after some cleanup, and with one problem, >> found while preparing the pull request, fixed. >> Even though typical scenarios for a UI application should be covered, it's not a complete solution. In particular, emoji-s >> still won't be rendered for large font sizes (more than 100pt), and for non-trivial composite/painting modes. >> Notable implementation details are listed below. >> >> **Glyph image generation** >> >> Deprecated CGContextShowGlyphsAtPoint function, used by JDK on macOS to render text, cannot render emojis, >> CTFontDrawGlyphs is used instead. It ignores the scale component of text transformation matrix, so a 'real-sized' >> CTFont object should be passed to it. The same sizing procedure is done when calculating glyph metrics, because they >> are not scaled proportionally with font size (as they do for vector fonts). >> >> **Glyph image storage** >> >> Existing GlyphInfo structure is used to store color glyph image. Color glyph can be distinguished by having 4 bytes >> of storage per pixel. Color components are stored in pre-multiplied alpha format. >> >> **Glyph rendering** >> >> Previously, GlyphList instance always contained glyphs in the same format (solid, grayscale or LCD), determined by the >> effective rendering hint. Now the renderers must be prepared to GlyphList having 'normal' glyphs interspersed with >> color glyphs (they can appear due to font fallback). This isn't a problem for OpenGL renderer (used for on-screen painting), >> but GlyphListLoopPipe-based renderers (used for off-screen painting) needed an adjustment to be able to operate on >> specific segments of GlyphList. >> As an incidental optimization, calculation of GlyphList bounds ('getBounds' method) is performed now only when needed >> (most text renderers don't need this information). >> Speaking of the actual rendering of the glyph image, it's done by the straightforward glDrawPixels call in OpenGL renderer, >> and by re-using existing Blit primitive in off-screen renderers. >> >> **Testing** >> >> There's no good way to test the new functionality automatically, but I've added a test verifying that 'something' is >> rendered for the emoji character, when painting to BufferedImage. >> >> Existing tests pass after the change. > > Dmitry Batrak has updated the pull request incrementally with two additional commits since the last revision: > > - 8263583: Emoji rendering on macOS > > extended test case to cover different types of target surfaces > - 8263583: Emoji rendering on macOS > > implementation for Metal rendering pipeline Any chance for a second review? ------------- PR: https://git.openjdk.java.net/jdk/pull/3007 From brian.burkhalter at oracle.com Tue Apr 20 20:38:33 2021 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 20 Apr 2021 20:38:33 +0000 Subject: [OpenJDK 2D-Dev] Image parsing spams stack traces to System.err In-Reply-To: References: Message-ID: <6DD29BB3-96AB-4B49-8074-459A4741B5B8@oracle.com> I think this post needs to go to 2d-dev (copied). > On Apr 20, 2021, at 9:58 AM, Lapo Luchini wrote: > > In both OpenJDK 8, 11 and 15 I verified that: > > sun/awt/image/InputStreamImageSource.java > > has "e.printStackTrace()" commands that might better be converted to java.util.logging in order to be able to configure/redirect them to the proper log file each application might decide to use. > > A little bit of more details as reported here (where they suggested this was the proper place): > https://github.com/AdoptOpenJDK/openjdk-jdk11u/issues/21 > > cheers, > > -- > Lapo Luchini > lapo at lapo.it > From philip.race at oracle.com Tue Apr 20 21:42:10 2021 From: philip.race at oracle.com (Philip Race) Date: Tue, 20 Apr 2021 14:42:10 -0700 Subject: [OpenJDK 2D-Dev] Image parsing spams stack traces to System.err In-Reply-To: <6DD29BB3-96AB-4B49-8074-459A4741B5B8@oracle.com> References: <6DD29BB3-96AB-4B49-8074-459A4741B5B8@oracle.com> Message-ID: 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 be clear to whoever hit it. This case shows it is not so clear cut. -phil. On 4/20/21 1:38 PM, Brian Burkhalter wrote: > I think this post needs to go to 2d-dev (copied). > >> On Apr 20, 2021, at 9:58 AM, Lapo Luchini wrote: >> >> In both OpenJDK 8, 11 and 15 I verified that: >> >> sun/awt/image/InputStreamImageSource.java >> >> has "e.printStackTrace()" commands that might better be converted to java.util.logging in order to be able to configure/redirect them to the proper log file each application might decide to use. >> >> A little bit of more details as reported here (where they suggested this was the proper place): >> https://github.com/AdoptOpenJDK/openjdk-jdk11u/issues/21 >> >> cheers, >> >> -- >> Lapo Luchini >> lapo at lapo.it >> From lapo at lapo.it Wed Apr 21 06:53:28 2021 From: lapo at lapo.it (Lapo Luchini) Date: Wed, 21 Apr 2021 08:53:28 +0200 Subject: [OpenJDK 2D-Dev] Image parsing spams stack traces to System.err In-Reply-To: References: <6DD29BB3-96AB-4B49-8074-459A4741B5B8@oracle.com> Message-ID: Thanks for creating it! I thought that? but I don't have an account and I don't think I can. "Everyone with OpenJDK Author status or above has a JBS account which may be used to create and edit bugs." https://bugs.openjdk.java.net/secure/Dashboard.jspa On 2021-04-20 23:42, Philip Race wrote: > 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 be clear to whoever hit it. This case shows it is not so clear cut. From shade at openjdk.java.net Wed Apr 21 12:36:34 2021 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Wed, 21 Apr 2021 12:36:34 GMT Subject: [OpenJDK 2D-Dev] RFR: JDK-8263467: Incorrect double-checked locking in sun.java2d.CRenderer [v2] In-Reply-To: References: Message-ID: <8YAIVTrN582qmS7bGwnD8s4ReTgfx73iyv557rhABZo=.c4506b08-7b7e-48a7-9faa-b3a0d1bd2b80@github.com> On Fri, 12 Mar 2021 07:22:26 GMT, Aleksey Shipilev wrote: >> SonarCloud reports multiple incorrect double-checked locking cases in `sun.java2d.CRenderer`. For example: >> >> >> Arc2D arcToShape; >> >> ... >> if (arcToShape == null) { >> synchronized (this) { >> if (arcToShape == null) { >> arcToShape = new Arc2D.Float(); >> } >> } >> } >> >> >> `Arc2D` contains fields that are not `final`. `arcToShape` is not `volatile`. This makes it an incorrect DCL. >> This code is used by Mac OS, do it would probably blow up some time later on M1. >> >> This is the candidate fix that preserves the semantics. I am doing this fix blindly so far, without testing on real Mac OS. But maybe there is no need to do any of this, because the setter methods overwrite the contents of all these objects under their own sync. So, maybe we can just allocate those objects without DCL-backed caching and pass them in? > > Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision: > > Drop DCL and useless synchronization completely Not now, bot. ------------- PR: https://git.openjdk.java.net/jdk/pull/2948 From duke at openjdk.java.net Wed Apr 21 13:38:41 2021 From: duke at openjdk.java.net (duke) Date: Wed, 21 Apr 2021 13:38:41 GMT Subject: [OpenJDK 2D-Dev] Withdrawn: 8257733: Move module-specific data from make to respective module In-Reply-To: References: Message-ID: On Thu, 3 Dec 2020 23:44:20 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 > > - [x] java.base > - [x] java.desktop > - [x] jdk.compiler > - [x] java.se This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.java.net/jdk/pull/1611 From tnakamura at openjdk.java.net Thu Apr 22 09:46:32 2021 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Thu, 22 Apr 2021 09:46:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled Message-ID: Hi, Could you review the fix? When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts. The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path. Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice. Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. Regards, Toshio Nakamura ------------- Commit messages: - 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled Changes: https://git.openjdk.java.net/jdk/pull/3619/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3619&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240756 Stats: 12 lines in 1 file changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3619.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3619/head:pull/3619 PR: https://git.openjdk.java.net/jdk/pull/3619 From alexsch at openjdk.java.net Thu Apr 22 15:19:39 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 22 Apr 2021 15:19:39 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows Message-ID: PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. The reason is that such docs use fonts which have empty font family name. The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. The PrintFontSample program draws a text using three methods: - Graphics2D.drawString(...) - Graphics2D.drawGlyphVector(...) - Graphics2D.drawGlyphVector(...) using transformed glyphs Running the program with jdk 16 on Windows (without the fix) > java PrintFontSample SampleBowMissedFamilyName.ttf shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. ------------- Commit messages: - 8265761: Font with missed font family name is not properly printed on Windows Changes: https://git.openjdk.java.net/jdk/pull/3631/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3631&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8265761 Stats: 292 lines in 3 files changed: 292 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3631/head:pull/3631 PR: https://git.openjdk.java.net/jdk/pull/3631 From alexsch at openjdk.java.net Thu Apr 22 19:19:25 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Thu, 22 Apr 2021 19:19:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. The `java/awt/print` and `java/awt/PrintJob` automated and manual tests were run with the fix. The automated tests pass. The following manual tests fail with and without the fix: java/awt/print/Dialog/DialogOrient.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/Dialog/DialogType.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/ImagePrinting/ClippedImages.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/ImagePrinting/ImageTypes.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/ImagePrinting/PrintARGBImage.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PageDialogTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PageRanges.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PageRangesDlgTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PrintGlyphVectorTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PrintLatinCJKTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/PrintTextTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/PrinterJob/SwingUIText.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/PrintJob/PageSetupDlgBlockingTest/PageSetupDlgBlockingTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/PrintJob/SaveDialogTitleTest.java Error. Parse Exception: Arguments to `manual' option not supported: yesno java/awt/print/Dialog/PrintDlgPageable.java Error. java.lang.IllegalAccessException: class com.sun.javatest.regtest.agent.MainWrapper$MainThread cannot access a member of class PrintDlgPageable with modifiers "public static" java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java Error. Can't find HTML file: test\jdk\java\awt\PrintJob\PrintCheckboxTest\PrintCheckboxManualTest.html ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From serb at openjdk.java.net Fri Apr 23 06:52:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 23 Apr 2021 06:52:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled In-Reply-To: References: Message-ID: <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com> On Thu, 22 Apr 2021 09:21:20 GMT, Toshio Nakamura wrote: > Hi, > > Could you review the fix? > When non-English characters were printed from JTable on MacOS, CTextPipe.doDrawGlyphs was called by OSXSurfaceData.drawGlyphs. However, CTextPipe seems not support glyph with slot number of composite fonts. > > The slot data mask of GlyphVector is 0xff000000. In my environment, Japanese font was loaded at slot 4, and glyph data is like [0x40003e5]. Then, unexpected glyph was drawn. > > This patch checks slot data of each character. If slot data exists, it will branch to GlyphVector's drawing path. > > Well, I couldn't create automatic test for this fix. This method seems to be called for printing only. I appreciate any advice. > Tested java/awt and javax/swing on MacOS BigSur, and there was no regression. > > Regards, > Toshio Nakamura As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font? ------------- PR: https://git.openjdk.java.net/jdk/pull/3619 From serb at openjdk.java.net Fri Apr 23 07:05:26 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 23 Apr 2021 07:05:26 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1160: > 1158: int rotation, float awScale) { > 1159: > 1160: if (family.isEmpty()) { Not sure that the non-empty family, but spaces only will work. ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From alexsch at openjdk.java.net Fri Apr 23 08:11:32 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 23 Apr 2021 08:11:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: <2sBDmVIa_JzdndfqaMomE4eFxSC94I0XyWFyqXn2gUM=.4479179b-8909-47f7-9fff-bc51cc7beb68@github.com> On Fri, 23 Apr 2021 07:02:45 GMT, Sergey Bylokhov wrote: >> PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. >> >> Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. >> >> The reason is that such docs use fonts which have empty font family name. >> The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. >> https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 >> >> The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: >> https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 >> >> To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. >> >> Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. >> >> The PrintFontSample program draws a text using three methods: >> - Graphics2D.drawString(...) >> - Graphics2D.drawGlyphVector(...) >> - Graphics2D.drawGlyphVector(...) using transformed glyphs >> >> Running the program with jdk 16 on Windows (without the fix) >>> java PrintFontSample SampleBowMissedFamilyName.ttf >> >> shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) >> Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) >> >> The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. > > src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1160: > >> 1158: int rotation, float awScale) { >> 1159: >> 1160: if (family.isEmpty()) { > > Not sure that the non-empty family, but spaces only will work. Would it be better to use isBlank() instead of isEmpty() to check a font family name is blank? if (family.isBlank()) { return false; } ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From tnakamura at openjdk.java.net Fri Apr 23 09:48:35 2021 From: tnakamura at openjdk.java.net (Toshio Nakamura) Date: Fri, 23 Apr 2021 09:48:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8240756: [macos] SwingSet2:TableDemo:Printed Japanese characters were garbled In-Reply-To: <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com> References: <4lgBU_G-xdIAebIcknY7c3Xg8BeWIVkLaWv6YlDSv1o=.37bf8684-d954-4dfb-8348-8d0a89464a38@github.com> Message-ID: <8Q74yMehR_J-kCb_2YKa0jDPSuyq5km4bc1t-P7xL0o=.27738de9-2500-4b38-83ba-e6c55b9ac43b@github.com> On Fri, 23 Apr 2021 06:49:10 GMT, Sergey Bylokhov wrote: > As far as I understand it is not directly related to the JTable and the bug is reproduced if some specific font is used when any text is printed? Did you check why the CTextPipe does not support it directly? It looks like the JavaCT_DrawGlyphVector uses pure core graphics, which I think should support this font? Hi Sergey, Thank you for the comments. JTable is not directly related, but it has child JComponents under texts. It's the trigger to meet the conditions to call the function. In this case, the font was specified as "LucidaGrande" or "Dialog" by L&F. Non English character to print is another condition. sun.font.CFont creates a composite font by the standard Mac cascade list. In my environment, font[4] is Japanese font, even if it's CFont("LucidaGrande"). CTextPipe.doDrawGlyphs uses one strike pointer, which is for one font. To support composite fonts, I think CTextPipe needs to handle array of strikes, and to switch fonts by slot data. I don't think this is a right way. CTextPipe.drawGlyphVector receives only GlyphVector data and no Unicode character data. So, we cannot use fallback methods. ------------- PR: https://git.openjdk.java.net/jdk/pull/3619 From avu at openjdk.java.net Fri Apr 23 11:25:32 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 23 Apr 2021 11:25:32 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 Message-ID: Explicitly set storeAction in clear pass for stencil texture ------------- Commit messages: - 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 Changes: https://git.openjdk.java.net/jdk/pull/3651/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264317 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3651/head:pull/3651 PR: https://git.openjdk.java.net/jdk/pull/3651 From serb at openjdk.java.net Fri Apr 23 16:19:23 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 23 Apr 2021 16:19:23 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 11:19:06 GMT, Alexey Ushakov wrote: > Explicitly set storeAction in clear pass for stencil texture Please add this bugid to the test. ------------- PR: https://git.openjdk.java.net/jdk/pull/3651 From avu at openjdk.java.net Fri Apr 23 18:43:47 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 23 Apr 2021 18:43:47 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 [v2] In-Reply-To: References: Message-ID: <_O3BTBylIvzBYFr-9Aw6mhpSmR3FugUvdYpE61JhvHk=.1d0d6a09-45be-4849-8162-24cbe8ef1cde@github.com> > Explicitly set storeAction in clear pass for stencil texture Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 Explicitly set storeAction in clear pass for stencil texture ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3651/files - new: https://git.openjdk.java.net/jdk/pull/3651/files/175c9075..bf569289 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3651&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3651&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3651.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3651/head:pull/3651 PR: https://git.openjdk.java.net/jdk/pull/3651 From avu at openjdk.java.net Fri Apr 23 18:47:23 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 23 Apr 2021 18:47:23 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 16:16:32 GMT, Sergey Bylokhov wrote: > Please add this bugid to the test. Done ------------- PR: https://git.openjdk.java.net/jdk/pull/3651 From serb at openjdk.java.net Fri Apr 23 20:03:25 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Fri, 23 Apr 2021 20:03:25 GMT Subject: [OpenJDK 2D-Dev] RFR: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 [v2] In-Reply-To: <_O3BTBylIvzBYFr-9Aw6mhpSmR3FugUvdYpE61JhvHk=.1d0d6a09-45be-4849-8162-24cbe8ef1cde@github.com> References: <_O3BTBylIvzBYFr-9Aw6mhpSmR3FugUvdYpE61JhvHk=.1d0d6a09-45be-4849-8162-24cbe8ef1cde@github.com> Message-ID: On Fri, 23 Apr 2021 18:43:47 GMT, Alexey Ushakov wrote: >> Explicitly set storeAction in clear pass for stencil texture > > Alexey Ushakov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 > > Explicitly set storeAction in clear pass for stencil texture Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3651 From philip.race at oracle.com Fri Apr 23 20:10:46 2021 From: philip.race at oracle.com (Philip Race) Date: Fri, 23 Apr 2021 13:10:46 -0700 Subject: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. Message-ID: <9826c9ab-273e-b387-a5f1-f44f855007f7@oracle.com> 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 JDK 17 build 23,meaning b22 will be the last build with Metal as default. See JEP 382 [2] for more information about how Metal is used by JDK. If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see any rendering related problems starting with JDK 17 b19, please do report them to us at either the usual bug submission channel [3], or on the 2d-dev at openjdk.java.net OpenJDK mailing list [4] Please be ready to provide us with a test case and screen shots. You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which? implicitly disables Metal - to confirm that any problem you see is a Metal related rendering glitch. I will also forward this email to jdk-dev at openjdk.java.net -Phil. [1] https://jdk.java.net/17/ [2] https://openjdk.java.net/jeps/382 [3] https://bugreport.java.com/bugreport/ [4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev From avu at openjdk.java.net Sun Apr 25 20:55:31 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Sun, 25 Apr 2021 20:55:31 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 In-Reply-To: References: Message-ID: On Fri, 23 Apr 2021 11:19:06 GMT, Alexey Ushakov wrote: > Explicitly set storeAction in clear pass for stencil texture This pull request has now been integrated. Changeset: 3bf4c904 Author: Alexey Ushakov Committer: Sergey Bylokhov URL: https://git.openjdk.java.net/jdk/commit/3bf4c904 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod 8264317: Lanai: IncorrectUnmanagedImageRotatedClip.java fails on apple M1 Reviewed-by: serb ------------- PR: https://git.openjdk.java.net/jdk/pull/3651 From serb at openjdk.java.net Sun Apr 25 20:56:56 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Sun, 25 Apr 2021 20:56:56 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: <2sBDmVIa_JzdndfqaMomE4eFxSC94I0XyWFyqXn2gUM=.4479179b-8909-47f7-9fff-bc51cc7beb68@github.com> References: <2sBDmVIa_JzdndfqaMomE4eFxSC94I0XyWFyqXn2gUM=.4479179b-8909-47f7-9fff-bc51cc7beb68@github.com> Message-ID: <_unf-1-9Z7lZWbW13pP4I3ofJ7EyHV_H-0VaxjNCUzo=.c9570a91-148b-4a9d-b2ee-31f898b9dacc@github.com> On Fri, 23 Apr 2021 08:08:29 GMT, Alexander Scherbatiy wrote: >> src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java line 1160: >> >>> 1158: int rotation, float awScale) { >>> 1159: >>> 1160: if (family.isEmpty()) { >> >> Not sure that the non-empty family, but spaces only will work. > > Would it be better to use isBlank() instead of isEmpty() to check a font family name is blank? > > if (family.isBlank()) { > return false; > } I think so. ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From alexsch at openjdk.java.net Mon Apr 26 20:02:44 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Mon, 26 Apr 2021 20:02:44 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: <_unf-1-9Z7lZWbW13pP4I3ofJ7EyHV_H-0VaxjNCUzo=.c9570a91-148b-4a9d-b2ee-31f898b9dacc@github.com> References: <2sBDmVIa_JzdndfqaMomE4eFxSC94I0XyWFyqXn2gUM=.4479179b-8909-47f7-9fff-bc51cc7beb68@github.com> <_unf-1-9Z7lZWbW13pP4I3ofJ7EyHV_H-0VaxjNCUzo=.c9570a91-148b-4a9d-b2ee-31f898b9dacc@github.com> Message-ID: <_dDWwWq4hwaHmzfN_jHrfDGfb-J3Lazx-yCDGzwV9Zk=.39c27736-201b-43c8-819f-d4a3b87b2d00@github.com> On Sun, 25 Apr 2021 20:53:11 GMT, Sergey Bylokhov wrote: >> Would it be better to use isBlank() instead of isEmpty() to check a font family name is blank? >> >> if (family.isBlank()) { >> return false; >> } > > I think so. I changed the test SampleBow font family name to one space [SampleBowOneSpaceFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94402/SampleBowOneSpaceFamilyName.ttf) and to two spaces [SampleBowTwoSpacesFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94403/SampleBowTwoSpacesFamilyName.ttf) The PrintFontSample sample program properly prints text drawn by Graphics2D.drawString() and Graphics2D.drawGlyphVector() on Windows with jdk 16 with these two fonts. It looks like the problem is only with selecting a font in GDI with empty font family name. ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From prr at openjdk.java.net Mon Apr 26 22:01:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Mon, 26 Apr 2021 22:01:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: <-QsVU4aiAu_oQoGhY6qQAaA482EhvzZeUwkh-_V5zqY=.c440a47d-2c02-4921-ab46-b5f651c1d39b@github.com> On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. I dumped the font you attached and it has Data: 43 6F 70 79 72 69 67 68 74 20 > Copyright 73 74 65 6C 6C 61 72 73 70 6F > stellarspo 74 20 32 30 32 31 > t 2021 Who are stellarspot ? We can't put their copyrighted font into openjdk. If you created this font by editing someone else's font that is a no-no. You would have to create a font from scratch and assert you own the font and the design of all glyphs and contribute it under OCA. The fix itself is probably fine .. I am surprised you get this far with a font with no name ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From alexsch at openjdk.java.net Tue Apr 27 08:28:38 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Tue, 27 Apr 2021 08:28:38 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. The stellarpot is my account which I used to create [SampleBow](https://fontstruct.com/fontstructions/show/1931451/samplebow) font in fontconstruct. I put a link to my github page in the fontconstruct [profile](https://fontstruct.com/fontstructors/1922537/stellarspot). If it is necessary, I can recreate the font or create an another font under my name and the required license. What is the right license that I can use to create a simple font for openjdk test? What is the way to contribute the font and the design of all glyphs under OCA? ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From aghaisas at openjdk.java.net Tue Apr 27 14:35:36 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Apr 2021 14:35:36 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v3] In-Reply-To: <1WDZ9bDY7yGTjiXqWN0RlHTH0ktjTlG42L8z4B1zPo8=.86125794-9f0d-46c1-abd7-713f75146a54@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> <1WDZ9bDY7yGTjiXqWN0RlHTH0ktjTlG42L8z4B1zPo8=.86125794-9f0d-46c1-abd7-713f75146a54@github.com> Message-ID: <2GBc6xPtSMJItW8mpMmHBLwDD8LI8KbsX6ITTdlCE0o=.d3d704c4-5b62-439e-8bc4-9b4ae612c126@github.com> On Fri, 9 Apr 2021 07:21:57 GMT, Sergey Bylokhov wrote: >> This is the only place where we use MTLContext.invalidateCurrentContext() - which when processed in MTLRenderQueue - clears some native stuff and nulls out both mtlc and dstOps pointers maintained in MTLRenderQueue.m. I think, this will be important once we get rid of SET_SCRATCH_SURFACE under JDK-8263309. > > But why you need to invalidate context here? Why do you need "clears some native stuff and nulls out both mtlc and dstOps pointers maintained in MTLRenderQueue.m"? > > In OGL the getCGLConfigInfo() change the state of the OGL state due to "makeCurrentContext", this is why we need to update the lava level state to "invalid", otherwise we will get a mismatch between the state in the native and java state. I see that MTLContext.invalidateCurrentContext() is not needed here. Also, as this is the only place it is used, we can remove the method altogether. ------------- PR: https://git.openjdk.java.net/jdk/pull/3357 From aghaisas at openjdk.java.net Tue Apr 27 14:42:17 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Apr 2021 14:42:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v4] In-Reply-To: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: <1Ju7UzWfhtuns-z8_QmeLseAGXmSqLxcjSgPfkHmFc0=.b93c069c-79af-43a4-9ea5-bfde7bd07ab1@github.com> > Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I was cleaning up. Ajit Ghaisas 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 five additional commits since the last revision: - cleanup MTLContext.invalidateCurrentContext() - Merge branch 'master' into cleanup_fix - log message correction - Review fixes - 8263363 - cleanup ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/45e7aec0..746d791d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=03 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=02-03 Stats: 130385 lines in 2601 files changed: 69070 ins; 53454 del; 7861 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357 From aghaisas at openjdk.java.net Tue Apr 27 14:59:57 2021 From: aghaisas at openjdk.java.net (Ajit Ghaisas) Date: Tue, 27 Apr 2021 14:59:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8263363: Minor cleanup of Lanai code - unused code removal and comments correction [v5] In-Reply-To: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> References: <32WDGVKFWTWk3jGJZouM_2tTLR6faMbHlADyp6ka4xM=.a1892b1a-4b76-4dd0-b0d2-6f4d6c76fc69@github.com> Message-ID: > Refer JBS for 3 issues that this PR addresses. > In addition, I have corrected an erroneous free() call in the same method I was cleaning up. Ajit Ghaisas has updated the pull request incrementally with one additional commit since the last revision: cleanup unused import ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3357/files - new: https://git.openjdk.java.net/jdk/pull/3357/files/746d791d..1cf7d1c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3357&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3357.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3357/head:pull/3357 PR: https://git.openjdk.java.net/jdk/pull/3357 From prr at openjdk.java.net Tue Apr 27 17:06:35 2021 From: prr at openjdk.java.net (Phil Race) Date: Tue, 27 Apr 2021 17:06:35 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. We don't have a lot of precedent here. Your name .. BellSoft .. Oracle .. OpenJDK .. nothing at all .. some message like "created for OpenJDK might help !". Something so that 10 years from now when someone looks at the font and has no reference back to this that they can say "Oh this is OK" and not "uh, oh, who is that ?" ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From ysuenaga at openjdk.java.net Wed Apr 28 06:00:19 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Wed, 28 Apr 2021 06:00:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266174: -Wmisleading-indentation happens in libmlib_image sources Message-ID: <3ynz2-4xL6qOKhkK9o7mwQdgPSYu8_iNRC7WhuQRdGg=.a1d46448-eab4-44d2-b73e-0464f964e2b3@github.com> We can see following warnings in mlib_ImageAffine_BC_S32.c, mlib_ImageAffine_BL_S32.c, mlib_ImageScanPoly.c . They are caused by indentation in mlib_ImageAffine.h . In file included from /home/ysuenaga/git-forked/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageAffine_BC_S32.c:65: ------------- Commit messages: - 8266174: -Wmisleading-indentation happens in libmlib_image sources Changes: https://git.openjdk.java.net/jdk/pull/3743/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3743&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266174 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/3743.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3743/head:pull/3743 PR: https://git.openjdk.java.net/jdk/pull/3743 From avu at openjdk.java.net Wed Apr 28 11:03:18 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Wed, 28 Apr 2021 11:03:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266040: Lanai: Incorrect calculations of clipping boundaries Message-ID: Adjust initial clipping values to correctly calculate shape clip boundary ------------- Commit messages: - 8266040: Lanai: Incorrect calculations of clipping boundaries Changes: https://git.openjdk.java.net/jdk/pull/3758/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3758&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266040 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jdk/pull/3758.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3758/head:pull/3758 PR: https://git.openjdk.java.net/jdk/pull/3758 From alexsch at openjdk.java.net Wed Apr 28 13:55:28 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 28 Apr 2021 13:55:28 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2] In-Reply-To: References: Message-ID: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: Update copyright in test font ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3631/files - new: https://git.openjdk.java.net/jdk/pull/3631/files/6b364341..1a75732b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3631&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3631&range=00-01 Stats: 2 lines in 3 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3631.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3631/head:pull/3631 PR: https://git.openjdk.java.net/jdk/pull/3631 From alexsch at openjdk.java.net Wed Apr 28 13:58:53 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Wed, 28 Apr 2021 13:58:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 13:55:28 GMT, Alexander Scherbatiy wrote: >> PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. >> >> Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. >> >> The reason is that such docs use fonts which have empty font family name. >> The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. >> https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 >> >> The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: >> https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 >> >> To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. >> >> Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. >> >> The PrintFontSample program draws a text using three methods: >> - Graphics2D.drawString(...) >> - Graphics2D.drawGlyphVector(...) >> - Graphics2D.drawGlyphVector(...) using transformed glyphs >> >> Running the program with jdk 16 on Windows (without the fix) >>> java PrintFontSample SampleBowMissedFamilyName.ttf >> >> shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) >> Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) >> >> The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright in test font I updated the font so now it uses "Alexander Scherbatiy" as a designer, "SampleFont Regular created for OpenJDK" as name for humans, and copyright: Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved. Copyright (c) 2021, BELLSOFT. All rights reserved. DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From serb at openjdk.java.net Wed Apr 28 18:23:53 2021 From: serb at openjdk.java.net (Sergey Bylokhov) Date: Wed, 28 Apr 2021 18:23:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 13:55:28 GMT, Alexander Scherbatiy wrote: >> PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. >> >> Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. >> >> The reason is that such docs use fonts which have empty font family name. >> The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. >> https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 >> >> The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: >> https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 >> >> To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. >> >> Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. >> >> The PrintFontSample program draws a text using three methods: >> - Graphics2D.drawString(...) >> - Graphics2D.drawGlyphVector(...) >> - Graphics2D.drawGlyphVector(...) using transformed glyphs >> >> Running the program with jdk 16 on Windows (without the fix) >>> java PrintFontSample SampleBowMissedFamilyName.ttf >> >> shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) >> Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) >> >> The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright in test font Marked as reviewed by serb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From prr at openjdk.java.net Wed Apr 28 19:02:53 2021 From: prr at openjdk.java.net (Phil Race) Date: Wed, 28 Apr 2021 19:02:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8265761: Font with missed font family name is not properly printed on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 13:55:28 GMT, Alexander Scherbatiy wrote: >> PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. >> >> Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. >> >> The reason is that such docs use fonts which have empty font family name. >> The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. >> https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 >> >> The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: >> https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 >> >> To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. >> >> Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. >> >> The PrintFontSample program draws a text using three methods: >> - Graphics2D.drawString(...) >> - Graphics2D.drawGlyphVector(...) >> - Graphics2D.drawGlyphVector(...) using transformed glyphs >> >> Running the program with jdk 16 on Windows (without the fix) >>> java PrintFontSample SampleBowMissedFamilyName.ttf >> >> shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) >> Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) >> >> The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. > > Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright in test font Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From azvegint at openjdk.java.net Thu Apr 29 00:17:50 2021 From: azvegint at openjdk.java.net (Alexander Zvegintsev) Date: Thu, 29 Apr 2021 00:17:50 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266174: -Wmisleading-indentation happens in libmlib_image sources In-Reply-To: <3ynz2-4xL6qOKhkK9o7mwQdgPSYu8_iNRC7WhuQRdGg=.a1d46448-eab4-44d2-b73e-0464f964e2b3@github.com> References: <3ynz2-4xL6qOKhkK9o7mwQdgPSYu8_iNRC7WhuQRdGg=.a1d46448-eab4-44d2-b73e-0464f964e2b3@github.com> Message-ID: On Wed, 28 Apr 2021 01:21:15 GMT, Yasumasa Suenaga wrote: > We can see following warnings in mlib_ImageAffine_BC_S32.c, mlib_ImageAffine_BL_S32.c, mlib_ImageScanPoly.c . They are caused by indentation in mlib_ImageAffine.h . > > > In file included from /home/ysuenaga/git-forked/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageAffine_BC_S32.c:65: Marked as reviewed by azvegint (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3743 From ysuenaga at openjdk.java.net Thu Apr 29 04:24:52 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 04:24:52 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8266174: -Wmisleading-indentation happens in libmlib_image sources In-Reply-To: <3ynz2-4xL6qOKhkK9o7mwQdgPSYu8_iNRC7WhuQRdGg=.a1d46448-eab4-44d2-b73e-0464f964e2b3@github.com> References: <3ynz2-4xL6qOKhkK9o7mwQdgPSYu8_iNRC7WhuQRdGg=.a1d46448-eab4-44d2-b73e-0464f964e2b3@github.com> Message-ID: On Wed, 28 Apr 2021 01:21:15 GMT, Yasumasa Suenaga wrote: > We can see following warnings in mlib_ImageAffine_BC_S32.c, mlib_ImageAffine_BL_S32.c, mlib_ImageScanPoly.c . They are caused by indentation in mlib_ImageAffine.h . > > > In file included from /home/ysuenaga/git-forked/jdk/src/java.desktop/share/native/libmlib_image/mlib_ImageAffine_BC_S32.c:65: This pull request has now been integrated. Changeset: 49372149 Author: Yasumasa Suenaga URL: https://git.openjdk.java.net/jdk/commit/49372149e529367171e0cabc842590ffd53e642d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8266174: -Wmisleading-indentation happens in libmlib_image sources Reviewed-by: azvegint ------------- PR: https://git.openjdk.java.net/jdk/pull/3743 From psadhukhan at openjdk.java.net Thu Apr 29 08:04:03 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 29 Apr 2021 08:04:03 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java Message-ID: It seems the newly deproblemlisted test DrawRotatedStringUsingRotatedFont.java which is paasing in windows,linux-x64 and macos-x64 is failing in newly added linux-aarch64 systems. Problemlisting the test for now as it is font layout issue which might need some upgrade in harfbuzz library in those CI systems or maybe in product. ------------- Commit messages: - 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java Changes: https://git.openjdk.java.net/jdk/pull/3790/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3790&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266284 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/3790.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3790/head:pull/3790 PR: https://git.openjdk.java.net/jdk/pull/3790 From jdv at openjdk.java.net Thu Apr 29 09:57:51 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Thu, 29 Apr 2021 09:57:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 07:57:17 GMT, Prasanta Sadhukhan wrote: > It seems the newly deproblemlisted test DrawRotatedStringUsingRotatedFont.java which is paasing in windows,linux-x64 and macos-x64 is failing in newly added linux-aarch64 systems. > Problemlisting the test for now as it is font layout issue which might need some upgrade in harfbuzz library in those CI systems or maybe in product. Marked as reviewed by jdv (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3790 From psadhukhan at openjdk.java.net Thu Apr 29 10:40:54 2021 From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan) Date: Thu, 29 Apr 2021 10:40:54 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 07:57:17 GMT, Prasanta Sadhukhan wrote: > It seems the newly deproblemlisted test DrawRotatedStringUsingRotatedFont.java which is paasing in windows,linux-x64 and macos-x64 is failing in newly added linux-aarch64 systems. > Problemlisting the test for now as it is font layout issue which might need some upgrade in harfbuzz library in those CI systems or maybe in product. This pull request has now been integrated. Changeset: 5574922f Author: Prasanta Sadhukhan URL: https://git.openjdk.java.net/jdk/commit/5574922ff69e976bf29f1d766a4c1a67d341ef8c Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java Reviewed-by: jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3790 From ysuenaga at openjdk.java.net Thu Apr 29 13:10:10 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Thu, 29 Apr 2021 13:10:10 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266171: -Warray-bounds happens in imageioJPEG.c Message-ID: <0NluQjOgb4c6J1CzHwb1GlIgEFx5mXRVU2QX1Yg5R3M=.a72423cf-59c9-4350-a0ce-dea174144d28@github.com> We can see following compiler warnings in imageioJPEG.c on GCC 11. ------------- Commit messages: - 8266171: -Warray-bounds happens in imageioJPEG.c Changes: https://git.openjdk.java.net/jdk/pull/3788/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3788&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266171 Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3788.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3788/head:pull/3788 PR: https://git.openjdk.java.net/jdk/pull/3788 From kizune at openjdk.java.net Thu Apr 29 14:52:54 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 14:52:54 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Fri, 2 Apr 2021 21:20:49 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 276: > >> 274: * >> 275: * @param f a File object >> 276: * @param size width and height of the icon in pixels > > Pixels could be ambiguous now. Usually, Swing deals with user's space. That is 16?16 icon should actually be 32?32 if the scale factor of the current display is 200%. > > Yes, this issue is somewhat irrelevant because the method returns multi-resolution icon. However, the terminology used must be unambiguous and clear; for consistency with other Swing API, it should be in terms of user's space coordinates, *virtual pixels*. Ok, fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Thu Apr 29 15:02:52 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 15:02:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: <3IvJU9r5uoMB68PVBZ8fGa6TdalgcISznUWZcnrfivY=.07798fce-f9ba-4443-84aa-52129e1e6a77@github.com> On Wed, 10 Mar 2021 20:32:12 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1195: > >> 1193: */ >> 1194: static Image getShell32Icon(int iconID, int size) { >> 1195: boolean useVGAColors = true; // Will be ignored on XP and later > > I cannot see where `useVGAColors` is used. Since the supported OS are later than XP, it can be removed, can't it? I think so. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Thu Apr 29 17:06:58 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 17:06:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:27:44 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114: > >> 1112: bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2); >> 1113: newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE >> 1114: : SMALL_ICON_SIZE, bothIcons); > > I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`. > > You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache. > > My opinion hasn't changed here. > > I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%? Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From prr at openjdk.java.net Thu Apr 29 17:17:04 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 29 Apr 2021 17:17:04 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266284: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java In-Reply-To: References: Message-ID: <7cpNcsGxcUY4zw9Swy8j0V_QRxAinoa4E11bYC2bZ1Q=.8ab040ff-be6e-474a-b088-04b87e7f0741@github.com> On Thu, 29 Apr 2021 07:57:17 GMT, Prasanta Sadhukhan wrote: > It seems the newly deproblemlisted test DrawRotatedStringUsingRotatedFont.java which is paasing in windows,linux-x64 and macos-x64 is failing in newly added linux-aarch64 systems. > Problemlisting the test for now as it is font layout issue which might need some upgrade in harfbuzz library in those CI systems or maybe in product. The linux aarch 64 systems aren't newly added. They've been there for > 1 year So why was this not seen whilst testing ? ------------- PR: https://git.openjdk.java.net/jdk/pull/3790 From kizune at openjdk.java.net Thu Apr 29 18:49:55 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Thu, 29 Apr 2021 18:49:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:17:05 GMT, Alexey Ivanov wrote: >> Fix updated after first round of review. > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044: > >> 1042: new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB); >> 1043: img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize); >> 1044: return img; > > There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case. Actually in makeImage we do not use requested size, we return the bits that system returns to us. How the generated image is treated depends on the implementation of the public methods - where it matters they are wrapped in the corresponding multi resolution images so it behaves correctly in UI. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From prr at openjdk.java.net Thu Apr 29 20:57:51 2021 From: prr at openjdk.java.net (Phil Race) Date: Thu, 29 Apr 2021 20:57:51 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266171: -Warray-bounds happens in imageioJPEG.c In-Reply-To: <0NluQjOgb4c6J1CzHwb1GlIgEFx5mXRVU2QX1Yg5R3M=.a72423cf-59c9-4350-a0ce-dea174144d28@github.com> References: <0NluQjOgb4c6J1CzHwb1GlIgEFx5mXRVU2QX1Yg5R3M=.a72423cf-59c9-4350-a0ce-dea174144d28@github.com> Message-ID: On Thu, 29 Apr 2021 07:10:33 GMT, Yasumasa Suenaga wrote: > We can see following compiler warnings in imageioJPEG.c on GCC 11. src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 673: > 671: if (info->is_decompressor) { > 672: j_decompress_ptr dinfo = (j_decompress_ptr) info; > 673: #ifdef __GNUC__ I know how these structs are defined but I am not sure how gcc can decide anything like this. I'd almost worry if it were true that we had the other type despite what the flag said except I can't imagine gcc is doing even any static analysis of the code calling sequence and you may even need a dynamic analysis for this. Have you submitted a gcc bug ? Why is it only complaining in this branch ? Have you considered disabling the warning in the make files - with broader scope of course - but a simpler change ? Is 520 bytes the actual size of the compress struct ? And even then I am not sure I know what the compiler message means. so long as we have the right starting address free will only free what was allocated ... surely ... ------------- PR: https://git.openjdk.java.net/jdk/pull/3788 From ysuenaga at openjdk.java.net Fri Apr 30 00:20:58 2021 From: ysuenaga at openjdk.java.net (Yasumasa Suenaga) Date: Fri, 30 Apr 2021 00:20:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266171: -Warray-bounds happens in imageioJPEG.c In-Reply-To: References: <0NluQjOgb4c6J1CzHwb1GlIgEFx5mXRVU2QX1Yg5R3M=.a72423cf-59c9-4350-a0ce-dea174144d28@github.com> Message-ID: On Thu, 29 Apr 2021 20:54:47 GMT, Phil Race wrote: >> We can see following compiler warnings in imageioJPEG.c on GCC 11. > > src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 673: > >> 671: if (info->is_decompressor) { >> 672: j_decompress_ptr dinfo = (j_decompress_ptr) info; >> 673: #ifdef __GNUC__ > > I know how these structs are defined but I am not sure how gcc can decide anything like this. > I'd almost worry if it were true that we had the other type despite what the flag said except I can't > imagine gcc is doing even any static analysis of the code calling sequence and you may even need a dynamic analysis for this. > > Have you submitted a gcc bug ? > Why is it only complaining in this branch ? > Have you considered disabling the warning in the make files - with broader scope of course - but a simpler change ? > > Is 520 bytes the actual size of the compress struct ? And even then I am not sure I know what the compiler message means. so long as we have the right starting address free will only free what was allocated ... surely ... I also think GCC does not do any static analysis of the code calling. And also the code uses `struct` like a C++ class, so I guess GCC reports incorrect warnings at this point. Many -Warray-bounds related issues are reported in [GCC Bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456). Especially it does not seem to work when the value is accessed by a pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99474 - it looks alike to me. WebKit seems to encounter [similar issue](https://bugs.webkit.org/show_bug.cgi?id=224782), they has avoided it with pragma. I concidered to disable it with a compiler option in makefile of course as you said, but I didn't do so because I heard in other review (I forget the JBS ticket) that we should disable warnings locally because they might be useful in future. ------------- PR: https://git.openjdk.java.net/jdk/pull/3788 From kizune at openjdk.java.net Fri Apr 30 05:41:19 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 05:41:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v2] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Small fixes Remived size parameter from makeIcon Removed useVGAColors usage as irrelevant since it is ignored on all supported platforms now ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/19a0efe0..6607b61f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=00-01 Stats: 27 lines in 3 files changed: 0 ins; 8 del; 19 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From alexsch at openjdk.java.net Fri Apr 30 08:50:57 2021 From: alexsch at openjdk.java.net (Alexander Scherbatiy) Date: Fri, 30 Apr 2021 08:50:57 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8265761: Font with missed font family name is not properly printed on Windows In-Reply-To: References: Message-ID: <23QHfJWL_8uxysYtpnjhq7OAaXWfdY64wFNroegkH3g=.dbbae55d-9bcf-4e5c-b0fc-d828183637e4@github.com> On Thu, 22 Apr 2021 15:13:45 GMT, Alexander Scherbatiy wrote: > PDFBox 1.8 uses [Graphics2D.drawGlyphVector()](https://github.com/apache/pdfbox/blob/41ae21bd4c3f304373d3b05f63af5325df248019/pdfbox/src/main/java/org/apache/pdfbox/pdmodel/font/PDSimpleFont.java#L352) method with scaled glyphs to print a text and PDF 2.0 uses [Graphics2D.fill()](https://github.com/apache/pdfbox/blob/4f14dee47ff821e44d9e2ff11532959d95e94d5b/pdfbox/src/main/java/org/apache/pdfbox/rendering/PageDrawer.java#L512) to print glyphs path. Both methods finally calls WPathGraphics.convertToWPath(...) in jdk on Windows which call GDI FillPath. > > Using a custom PageDrawer to draw a text in PDFBox with Graphics2D.drawString() method reveals the fact that some pdf documents which are properly printed by PDFBox 1.8 and PDF 2.0 on Linux and Windows have issues with printing them on Windows. > > The reason is that such docs use fonts which have empty font family name. > The awt_PrintJob.jFontToWFontA(...) method is not able to select the required font when the passed font family name is empty. > https://github.com/openjdk/jdk/blob/7c37c022a1664437bf8d2c8d76ad039521f3ffa7/src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp#L2264 > > The proposed solution returns false from WPrinterJob.setFont(...) method when the font family is empty so the text printing falls back to printing a text by GDI FillPath method: > https://github.com/openjdk/jdk/blob/6d49cc3b655433d00e967fdcec3f3759412cd925/src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java#L1157 > > To reproduce the issue I created a simple [SampleBowMissedFamilyName.ttf](https://bugs.openjdk.java.net/secure/attachment/94344/SampleBowMissedFamilyName.ttf) font which contains only capital letters "ABCDEF" and saved it with empty font family name. > > Here is a simple [PrintFontSample.java](https://bugs.openjdk.java.net/secure/attachment/94343/PrintFontSample.java) program that helps to reproduce the issue using the SampleBowMissedFamilyName.ttf font. > > The PrintFontSample program draws a text using three methods: > - Graphics2D.drawString(...) > - Graphics2D.drawGlyphVector(...) > - Graphics2D.drawGlyphVector(...) using transformed glyphs > > Running the program with jdk 16 on Windows (without the fix) >> java PrintFontSample SampleBowMissedFamilyName.ttf > > shows that the first and the second lines are not properly printed: [sample-doc-without-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94345/sample-doc-without-fix.pdf) > Running the program with the fix properly prints all three lines: [sample-doc-with-fix.pdf](https://bugs.openjdk.java.net/secure/attachment/94349/sample-doc-with-fix.pdf) > > The provided manual test uses the created SampleBowMissedFamilyName.ttf font with empty font family name. This pull request has now been integrated. Changeset: e9370a13 Author: Alexander Scherbatiy URL: https://git.openjdk.java.net/jdk/commit/e9370a13b6f3f99d223ef5966f9e218b94d954b4 Stats: 293 lines in 3 files changed: 293 ins; 0 del; 0 mod 8265761: Font with missed font family name is not properly printed on Windows Reviewed-by: serb, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/3631 From jdv at openjdk.java.net Fri Apr 30 10:55:52 2021 From: jdv at openjdk.java.net (Jayathirth D V) Date: Fri, 30 Apr 2021 10:55:52 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266040: Lanai: Incorrect calculations of clipping boundaries In-Reply-To: References: Message-ID: <3wbKPePWQgJHdF_TWBP2ovQbSRfwp_IhTjyc6fEz9JU=.8d54a968-cc70-47fc-9e73-a9840220e297@github.com> On Wed, 28 Apr 2021 10:55:48 GMT, Alexey Ushakov wrote: > Adjust initial clipping values to correctly calculate shape clip boundary LGTM. jtreg and JCK all test run is fine. J2DDemo and SwingSet2 looks good. Ran RenderPerfTest and saw improvement in ClipFlatOval/ClipFlatOvalAA from ~10FPS to ~14FPS in my machine. ------------- Marked as reviewed by jdv (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/3758 From kizune at openjdk.java.net Fri Apr 30 12:27:20 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 12:27:20 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:44:19 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 264: > >> 262: *

>> 263: * The default implementation gets information from the >> 264: * ShellFolder class. Whenever possible, the icon > > Do we continue using `` elements? I thought that {@code} is the preferred way to markup class names. Fixed. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From kizune at openjdk.java.net Fri Apr 30 12:27:19 2021 From: kizune at openjdk.java.net (Alexander Zuev) Date: Fri, 30 Apr 2021 12:27:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: > Fix updated after first round of review. Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp Select one icon at a time. Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/2875/files - new: https://git.openjdk.java.net/jdk/pull/2875/files/6607b61f..4a360621 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2875&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/2875.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/2875/head:pull/2875 PR: https://git.openjdk.java.net/jdk/pull/2875 From avu at openjdk.java.net Fri Apr 30 13:56:59 2021 From: avu at openjdk.java.net (Alexey Ushakov) Date: Fri, 30 Apr 2021 13:56:59 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8266040: Lanai: Incorrect calculations of clipping boundaries In-Reply-To: References: Message-ID: On Wed, 28 Apr 2021 10:55:48 GMT, Alexey Ushakov wrote: > Adjust initial clipping values to correctly calculate shape clip boundary This pull request has now been integrated. Changeset: 87de5b75 Author: Alexey Ushakov Committer: Jayathirth D V URL: https://git.openjdk.java.net/jdk/commit/87de5b750d2289512f002ecd307117734781f862 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod 8266040: Lanai: Incorrect calculations of clipping boundaries Reviewed-by: jdv ------------- PR: https://git.openjdk.java.net/jdk/pull/3758 From prr at openjdk.java.net Fri Apr 30 18:20:50 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 18:20:50 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266171: -Warray-bounds happens in imageioJPEG.c In-Reply-To: References: <0NluQjOgb4c6J1CzHwb1GlIgEFx5mXRVU2QX1Yg5R3M=.a72423cf-59c9-4350-a0ce-dea174144d28@github.com> Message-ID: On Fri, 30 Apr 2021 00:18:15 GMT, Yasumasa Suenaga wrote: >> src/java.desktop/share/native/libjavajpeg/imageioJPEG.c line 673: >> >>> 671: if (info->is_decompressor) { >>> 672: j_decompress_ptr dinfo = (j_decompress_ptr) info; >>> 673: #ifdef __GNUC__ >> >> I know how these structs are defined but I am not sure how gcc can decide anything like this. >> I'd almost worry if it were true that we had the other type despite what the flag said except I can't >> imagine gcc is doing even any static analysis of the code calling sequence and you may even need a dynamic analysis for this. >> >> Have you submitted a gcc bug ? >> Why is it only complaining in this branch ? >> Have you considered disabling the warning in the make files - with broader scope of course - but a simpler change ? >> >> Is 520 bytes the actual size of the compress struct ? And even then I am not sure I know what the compiler message means. so long as we have the right starting address free will only free what was allocated ... surely ... > > I also think GCC does not do any static analysis of the code calling. And also the code uses `struct` like a C++ class, so I guess GCC reports incorrect warnings at this point. > Many -Warray-bounds related issues are reported in [GCC Bugzilla](https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456). Especially it does not seem to work when the value is accessed by a pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99474 - it looks alike to me. > > WebKit seems to encounter [similar issue](https://bugs.webkit.org/show_bug.cgi?id=224782), they has avoided it with pragma. > > I concidered to disable it with a compiler option in makefile of course as you said, but I didn't do so because I heard in other review (I forget the JBS ticket) that we should disable warnings locally because they might be useful in future. In this case the rest of the code here is unlikely to change so I think it is fine to put it in the build and it will be easier to revert it when gcc is fixed .. and since the warning looks like it is bogus more often than not wider blocking of it is probably OK anyway. But I am also sure this is the only case. ------------- PR: https://git.openjdk.java.net/jdk/pull/3788 From dcubed at openjdk.java.net Fri Apr 30 19:40:58 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:40:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 Message-ID: A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. ------------- Commit messages: - 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 Changes: https://git.openjdk.java.net/jdk/pull/3824/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266389 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3824/head:pull/3824 PR: https://git.openjdk.java.net/jdk/pull/3824 From mikael at openjdk.java.net Fri Apr 30 19:40:58 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:40:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64 In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:52:18 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:52:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Please make it generic ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:52:17 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:52:17 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/3824/files - new: https://git.openjdk.java.net/jdk/pull/3824/files/40fd5576..4750d33f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3824&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/3824.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3824/head:pull/3824 PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:52:19 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:52:19 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. Will do. ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:52:20 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:52:20 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:49:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. test/jdk/ProblemList.txt line 529: > 527: java/awt/MenuBar/TestNoScreenMenuBar.java 8265987 macosx-all > 528: > 529: java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java 8266283 linux-all generic like it used to be please ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From mikael at openjdk.java.net Fri Apr 30 19:52:18 2021 From: mikael at openjdk.java.net (Mikael Vidstedt) Date: Fri, 30 Apr 2021 19:52:18 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:49:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. Marked as reviewed by mikael (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:57:55 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:57:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:46:46 GMT, Mikael Vidstedt wrote: >> Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: >> >> Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. > > Marked as reviewed by mikael (Reviewer). @vidmik and @prrace - Thanks for the reviews! ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 19:57:55 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 19:57:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all [v2] In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:52:17 GMT, Daniel D. Daugherty wrote: >> A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. > > Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision: > > Use 'generic-all' for java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java entry. Marked as reviewed by prr (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From dcubed at openjdk.java.net Fri Apr 30 19:57:56 2021 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Fri, 30 Apr 2021 19:57:56 GMT Subject: [OpenJDK 2D-Dev] Integrated: 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all In-Reply-To: References: Message-ID: On Fri, 30 Apr 2021 19:32:43 GMT, Daniel D. Daugherty wrote: > A trivial fix to ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on linux-x64. This pull request has now been integrated. Changeset: 50fa1623 Author: Daniel D. Daugherty URL: https://git.openjdk.java.net/jdk/commit/50fa1623adca74f79413fd127d4338901da4678d Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8266389: ProblemList java/awt/Graphics2D/DrawString/DrawRotatedStringUsingRotatedFont.java on generic-all Reviewed-by: mikael, prr ------------- PR: https://git.openjdk.java.net/jdk/pull/3824 From prr at openjdk.java.net Fri Apr 30 20:14:22 2021 From: prr at openjdk.java.net (Phil Race) Date: Fri, 30 Apr 2021 20:14:22 GMT Subject: [OpenJDK 2D-Dev] RFR: 8261169: Upgrade HarfBuzz to the latest 2.8.0 Message-ID: Upgrade to harfbuzz 2.8 ------------- Commit messages: - 8261169: Upgrade HarfBuzz to the latest 2.8.0 Changes: https://git.openjdk.java.net/jdk/pull/3826/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3826&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8261169 Stats: 13120 lines in 123 files changed: 7021 ins; 2757 del; 3342 mod Patch: https://git.openjdk.java.net/jdk/pull/3826.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/3826/head:pull/3826 PR: https://git.openjdk.java.net/jdk/pull/3826 From aivanov at openjdk.java.net Fri Apr 30 20:40:57 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:40:57 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: <3hQNodTn6s3lrpoRv7bTa-fDV4OBwdEiHiV_vo3zJQY=.f5f64501-eb98-4ffa-83b1-b3841abf290b@github.com> On Fri, 30 Apr 2021 12:27:19 GMT, Alexander Zuev wrote: >> Fix updated after first round of review. > > Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp > > Select one icon at a time. > > Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 267: > 265: * returned will be a multi-resolution icon image, > 266: * which will allow better scaling with different > 267: * magnification factors. I'm not sure what are the standard terms to refer to High DPI environments and the scale factors associated with High DPI. src/java.desktop/share/classes/javax/swing/filechooser/FileSystemView.java line 275: > 273: * > 274: * > 275: * @param f a File object Suggestion: * @param f a {@code File} object src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java line 213: > 211: * Returns the icon of the specified size used to display this shell folder. > 212: * > 213: * @param size size of the icon > 0 (Valid range: 1 to 256) I'm unsure the valid range of 1 to 256 makes sense provided the icon smaller than 16?16 is never returned (on Windows at least). src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1193: > 1191: static Image getShell32Icon(int iconID, int size) { > 1192: Toolkit toolkit = Toolkit.getDefaultToolkit(); > 1193: String shellIconBPP = (String)toolkit.getDesktopProperty("win.icon.shellIconBPP"); Looks like these lines aren't used any more and should be removed too. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:40:58 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:40:58 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 18:47:27 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1044: >> >>> 1042: new BufferedImage(iconSize, iconSize, BufferedImage.TYPE_INT_ARGB); >>> 1043: img.setRGB(0, 0, iconSize, iconSize, iconBits, 0, iconSize); >>> 1044: return img; >> >> There are cases where the size of the buffered image is different from the requested size. It could affect the layout because it breaks the assumption that the returned image has the requested size but it may be larger. (Or is it no longer possible?) I think it should be wrapped into `MultiResolutionIconImage` in this case. > > Actually in makeImage we do not use requested size, we return the bits that system returns to us. How the generated image is treated depends on the implementation of the public methods - where it matters they are wrapped in the corresponding multi resolution images so it behaves correctly in UI. Okay, if it *always* wrapped in a multi-resolution image where it *matters*. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:50:55 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:50:55 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Thu, 29 Apr 2021 17:04:17 GMT, Alexander Zuev wrote: >> src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1114: >> >>> 1112: bothIcons.put(getLargeIcon? SMALL_ICON_SIZE : LARGE_ICON_SIZE, newIcon2); >>> 1113: newIcon = new MultiResolutionIconImage(getLargeIcon ? LARGE_ICON_SIZE >>> 1114: : SMALL_ICON_SIZE, bothIcons); >> >> I still propose to refactor this code to make it clearer. The code always returns two icons: _small + large_ or _large + small_ ? combined in `MultiResolutionIconImage`. >> >> You can get `smallIcon` and `largeIcon` and then wrap them into `MultiResolutionIconImage` in the correct order and store each icon in the cache. >> >> My opinion hasn't changed here. >> >> I still think there's not much value in getting smaller icon size in addition to larger one. Or does it provide an alternative image for the case where the system scaling is 200% and the window is moved to a monitor with scaling of 100%? > > Getting smaller icon is relevant in the case of the scaling. I do not think refactoring image caches from icons to multiresolution images will make code much cleaner - at the end we will have to extract images from the multiresolution image to repack them into different multiresolution image because the base size of the image will not be the same and it does matter in how they will be scaled on the different screens. And we still need to extract both images because sometimes small resolution image looks not like the large resolution one and for a reason - so small resolution image is not blurred by the small detail on the large icon when scaling on the low resolution screen. No, I can't see how it's relevant. If the scale factor is 100% and the requested icon size is 16, then 16?16 is used; if the window is moved to a monitor with scale factor 200%, then 32?32 icon is used for rendering which is already fetched and available in the multi-resolution image ? perfect, there's the benefit. But when is it possible that the scale factor is less than 100%? If `JFileChooser` requests a large icon that is 32?32, then it will be used for rendering when the scale factor is 100%. When the scale factor is 200%, the icon of 64?64 is required but it's not available, instead there's 16?16 icon. For this icon to be used, the scale factor needs to be 50%. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:53:53 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:53:53 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:40:40 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > test/jdk/javax/swing/JFileChooser/FileSystemView/SystemIconTest.java line 64: > >> 62: } >> 63: >> 64: if (icon.getIconWidth() != size) { > > Does it make sense to check that the icon is a multi-resolution image with the expected sizes? > We know for sure `explorer.exe` contains the entire set of icons. Since the test always expects a multi-resolution image, does it make sense to assert `icon instanceof MultiResolutionImage` at the very least? ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From aivanov at openjdk.java.net Fri Apr 30 20:57:02 2021 From: aivanov at openjdk.java.net (Alexey Ivanov) Date: Fri, 30 Apr 2021 20:57:02 GMT Subject: [OpenJDK 2D-Dev] RFR: 8182043: Access to Windows Large Icons [v3] In-Reply-To: References: Message-ID: On Wed, 10 Mar 2021 20:53:43 GMT, Alexey Ivanov wrote: >> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp >> >> Select one icon at a time. >> >> Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com> > > src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java line 1146: > >> 1144: } >> 1145: Map multiResolutionIcon = new HashMap<>(); >> 1146: int start = size > MAX_QUALITY_ICON ? ICON_RESOLUTIONS.length - 1 : 0; > > Does it make sense to always start at zero? > The icons of smaller size will never be used, will they? > Thus it's safe to start at the index which corresponds to the requested size if `size` matches, or the index such as `ICON_RESOLUTIONS[index] < size && ICON_RESOLUTIONS[index + 1] > size`. This comment is also about the case of not fetching icons of sizes smaller than requested size. ------------- PR: https://git.openjdk.java.net/jdk/pull/2875 From javalists at cbfiddle.com Fri Apr 30 02:18:47 2021 From: javalists at cbfiddle.com (Alan Snyder) Date: Thu, 29 Apr 2021 19:18:47 -0700 Subject: [OpenJDK 2D-Dev] Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. In-Reply-To: References: <9826c9ab-273e-b387-a5f1-f44f855007f7@oracle.com> Message-ID: <780AEA69-004A-4126-B495-A180F4068D92@cbfiddle.com> I am seeing some unusual behavior (in b20) that I do not see using OpenGL (or using JDK 16). Sometimes when I open a new window, the window appears blank (except for the title bar) for about two seconds before the content appears. This behavior is not consistent. Opening another instance of the same 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 cross-posting. > > -phil. > > > -------- Forwarded Message -------- > Subject: Heads up : JDK 17 b19 through b22 will use Metal instead of OpenGL for Java 2D rendering on macOS. > Date: Fri, 23 Apr 2021 13:10:46 -0700 > From: Philip Race > To: 2d-dev at openjdk.java.net <2d-dev at openjdk.java.net> > CC: lanai-dev at openjdk.java.net, swing-dev at openjdk.java.net , awt-dev at openjdk.java.net > > > > > 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 JDK 17 build 23,meaning b22 will be the last build with Metal as default. > > See JEP 382 [2] for more information about how Metal is used by JDK. > > If you are running any kind of 2D / Swing/ AWT UI application on macOS, and see any rendering related problems > starting with JDK 17 b19, please do report them to us at either the usual bug submission channel [3], > or on the 2d-dev at openjdk.java.net OpenJDK mailing list [4] > Please be ready to provide us with a test case and screen shots. > > You may also set "-Dsun.java2d.opengl=true" to re-enable OpenGL - which implicitly disables Metal - > to confirm that any problem you see is a Metal related rendering glitch. > > I will also forward this email to jdk-dev at openjdk.java.net > > -Phil. > > [1] https://jdk.java.net/17/ > [2] https://openjdk.java.net/jeps/382 > [3] https://bugreport.java.com/bugreport/ > [4] https://mail.openjdk.java.net/mailman/listinfo/2d-dev >