From philip.race at oracle.com Fri Dec 1 21:19:02 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 1 Dec 2017 13:19:02 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8182610: Update specification of service providers for IIORegistry and ServiceRegistry Message-ID: <140b772e-b422-3236-c9a8-ee4cf34096f7@oracle.com> This is a doc-only fix to point to ServiceLoader to explain how service providers work replacing the local incomplete documentation in these Image I/O classes. The existing docs pre-date the existence of ServiceLoader which of course is further updated in 9 to explain how to deliver service providers as modules. Bug: http://cr.openjdk.java.net/~prr/8182610/ Webrev: http://cr.openjdk.java.net/~prr/8182610/ Specdiff: http://cr.openjdk.java.net/~prr/8182610/iiospecdiff/package-summary.html -phil From paul.sandoz at oracle.com Fri Dec 1 22:58:48 2017 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 1 Dec 2017 14:58:48 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8182610: Update specification of service providers for IIORegistry and ServiceRegistry In-Reply-To: <140b772e-b422-3236-c9a8-ee4cf34096f7@oracle.com> References: <140b772e-b422-3236-c9a8-ee4cf34096f7@oracle.com> Message-ID: <187FE420-77C9-4F61-ACFF-C34E0834D77D@oracle.com> > On 1 Dec 2017, at 13:19, Phil Race wrote: > > This is a doc-only fix to point to ServiceLoader to explain how service providers work > replacing the local incomplete documentation in these Image I/O classes. > The existing docs pre-date the existence of ServiceLoader which of course is further > updated in 9 to explain how to deliver service providers as modules. > > Bug: http://cr.openjdk.java.net/~prr/8182610/ > Webrev: http://cr.openjdk.java.net/~prr/8182610/ > Specdiff: http://cr.openjdk.java.net/~prr/8182610/iiospecdiff/package-summary.html > +1 Paul. > -phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 873 bytes Desc: Message signed with OpenPGP URL: From Sergey.Bylokhov at oracle.com Sat Dec 2 03:02:37 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 Dec 2017 19:02:37 -0800 Subject: [OpenJDK 2D-Dev] [10] Review request for 8181659: Create an alternative fix for JDK-8167102, whose fix was backed out In-Reply-To: References: <3dd33e24-c92c-23a7-36b4-e241c12f01eb@oracle.com> <8aef1ea8-fff0-f800-97f5-039011218d6f@oracle.com> Message-ID: +1 On 28/11/2017 07:39, Anton Litvinov wrote: > Hello Phil, > > Thank you very much for review and approval of this fix. > > Thank you, > Anton > > On 27/11/2017 23:13, Phil Race wrote: >> Hi, >> >> getPageFormatFromAttributes(..) was added to fix some mac specific >> issues : >> https://bugs.openjdk.java.net/browse/JDK-8025988 >> https://bugs.openjdk.java.net/browse/JDK-8025990 which is why it is >> used only on mac, so I think it is OK to assume it can be modified to >> fix a further Mac bug. So this seems OK. -phil. >> >> >> On 11/23/2017 08:54 AM, Anton Litvinov wrote: >>> Hello Prasanta and Phil, >>> >>> Could you please review the following fix for the bug consisting in >>> creation of the alternative version of the fix for >>> (https://bugs.openjdk.java.net/browse/JDK-8167102). I am writing to >>> you directly, because you reviewed my first fix for this bug, which >>> then caused the bug >>> (https://bugs.openjdk.java.net/browse/JDK-8181192) and was backed out >>> by the fix for JDK-8181192. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181659 >>> Webrev: http://cr.openjdk.java.net/~alitvinov/8181659/jdk10/webrev.00 >>> >>> This fix is actually the first version of the fix for JDK-8167102 >>> with insignificant changes: >>> - edited comment text; >>> - 1 redundant check on equality to "null" is removed; >>> - exclusion of the regression test >>> "test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java" >>> developed for JDK-8167102 is cancelled by removal of "@ignore" tag >>> from the test. >>> >>> ADVANTAGES OF THE FIX: >>> >>> 1)? The fix is completely OS X specific, because the edited method >>> "sun.print.RasterPrinterJob.getPageFormatFromAttributes()" is invoked >>> only from the OS X native code in file >>> "src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m". >>> >>> 2)? Corrects the behavior of >>> "RasterPrinterJob.getPageFormatFromAttributes" method to return a new >>> "PageFormat" based on corresponding values of the existing >>> "PageFormat" set by the user through >>> "java.awt.print.PrinterJob.setPrintable(Printable, PageFormat)", if >>> the user does not supply "OrientationRequested", "MediaSizeName", >>> "MediaPrintableArea" attributes during the call to >>> "PrinterJob.print(PrintRequestAttributeSet)". >>> >>> 3) Eliminates the possibility of being blocked during the call >>> "Pageable.getPageFormat(int)", like it was with the previous version >>> of the fix, because now the fix calls "getPageFormat(int)" only for >>> "Pageable" of type "sun.print.OpenBook", which is used by JDK >>> especially, when "PageFormat" is the same for all pages of the >>> document, when the user calls "PrinterJob.setPrintable(Printable, >>> PageFormat)". >>> >>> I verified that this fix resolves the original bug JDK-8167102 and >>> does not cause the regression JDK-8181192. >>> >>> Thank you, >>> Anton >> > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Sat Dec 2 03:05:36 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 1 Dec 2017 19:05:36 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8182610: Update specification of service providers for IIORegistry and ServiceRegistry In-Reply-To: <187FE420-77C9-4F61-ACFF-C34E0834D77D@oracle.com> References: <140b772e-b422-3236-c9a8-ee4cf34096f7@oracle.com> <187FE420-77C9-4F61-ACFF-C34E0834D77D@oracle.com> Message-ID: <96c99354-d5c0-329f-fd11-c5228d2bfe1e@oracle.com> Looks fine. On 01/12/2017 14:58, Paul Sandoz wrote: > > >> On 1 Dec 2017, at 13:19, Phil Race wrote: >> >> This is a doc-only fix to point to ServiceLoader to explain how service providers work >> replacing the local incomplete documentation in these Image I/O classes. >> The existing docs pre-date the existence of ServiceLoader which of course is further >> updated in 9 to explain how to deliver service providers as modules. >> >> Bug: http://cr.openjdk.java.net/~prr/8182610/ >> Webrev: http://cr.openjdk.java.net/~prr/8182610/ >> Specdiff: http://cr.openjdk.java.net/~prr/8182610/iiospecdiff/package-summary.html >> > > +1 > > Paul. > >> -phil > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Dec 4 07:37:21 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 3 Dec 2017 23:37:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8188836: Upgrade to Harfbuzz 1.7.1 in JDK 10 In-Reply-To: References: Message-ID: <51da9889-3698-d721-4c7c-5e07e713c3ee@oracle.com> An update to the new Harfbuzz looks fine. On 30/11/2017 11:01, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8188836 > Webrev : http://cr.openjdk.java.net/~prr/8188836/ > > harfbuzz is the OpenType font layout engine in JDK 9 > JDK 9 uses harfbuzz 1.5.1 and JDK 10 should update to the most recent > version. > > This has been built on all supported platforms (and. FWIW the 32 bit > unsupported > ones as well) and as a consequence I had to make a few tweaks. > One for window and 3 others for Solaris > > On Windows+ Visual Studio 2013 > On Windows I had to make a JDK build change for this library to > disable Visual C++ error 4101 - unreferenced local variable. > > This is apparently down to debug code whereby if HB_DEBUG is off still > plants code like > > #define TRACE_CLOSURE(this) hb_no_trace_t trace HB_UNUSED > > The Solaris changes are as follows :- > > -- > > harfbuzz/hb-face.cc", line 493: Error: The operation "extern "C" > void(*)(void*) != void(*)(void*)" is illegal. > > The line it did not like is > ? if (face->destroy != _hb_face_for_data_closure_destroy) > > The fix is to declare hb_face_for_data_closure_destroy as extern "C" at > line 119 > in the same file if compiler is __SUNPRO_CC > > --- > hb-dsalgs.hh", line 80: Error: Badly formed expression. > hb-dsalgs.hh", line 82: Error: Use ";" to terminate declarations. > hb-dsalgs.hh", line 82: Error: "," expected instead of ")". > hb-dsalgs.hh", line 82: Error: Use ";" to terminate declarations. > hb-dsalgs.hh", line 82: Error: A declaration was expected instead of ",". > hb-dsalgs.hh", line 83: Error: "," expected instead of ")". > hb-dsalgs.hh", line 85: Error: Use ";" to terminate declarations. > hb-dsalgs.hh", line 85: Error: A declaration was expected instead of ",". > hb-dsalgs.hh", line 85: Error: a is not defined. > hb-dsalgs.hh", line 85: Error: w is not defined. > hb-dsalgs.hh", line 86: Error: A declaration was expected instead of "if". > hb-dsalgs.hh", line 86: Error: a is not defined. > > It turns out that the SunStudio compiler does not support "restrict" so > this line was not parsed correctly : > static int sort_r_cmpswap(char *__restrict a, char *__restrict b, size_t w, > > I changed it to > #ifndef __SUNPRO_CC > /* __restrict is same as restrict but better support on old machines */ > static int sort_r_cmpswap(char *__restrict a, char *__restrict b, size_t w, > #else > static int sort_r_cmpswap(char *a, char *b, size_t w, > #endif > > --- > > 3) hb-string-array.hh", line 51: Error: An array cannot have zero size > unless you use the option -features=zla. > > That turns out to be the union member str in this code : > #undef _S > ? } st; > ? char str[0]; > > Since you need 'str' just to get the offset of the beginning of the > array that is the other > member of this union and that is way bigger than the one extra byte I > decided it was > easiest and harmless to just change it to > > ? char str[1]; > --- > > These issues have been reported upstream .. some variation of these > fixes should make it into an upstream release before we need to upgrade > again. > > -phil. > > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Dec 4 22:09:49 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 4 Dec 2017 14:09:49 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip In-Reply-To: References: Message-ID: Hi, Laurent. On 29/11/2017 14:30, Laurent Bourg?s wrote: > - added new ClipShapeTest (jtreg) that checks all possible combinations > of (cap / join) for random polyline (Stroker) and polygons (Filler) > comparing image outputs rendered with clipping enabled vs disabled I have only one note that the test is passed before the fix, so if we will regress at some point later we will not catch this. -- Best regards, Sergey. From bourges.laurent at gmail.com Mon Dec 4 22:35:00 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 4 Dec 2017 23:35:00 +0100 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip In-Reply-To: References: Message-ID: Hi Sergey, Thanks for your comment. This new test only validates the new clipping algorithms ie it compares the rendering outputs with / without clipping enabled. As such algorithms are only available in Marlin 0.8.2 and the test uses new system properties to enable/disable clipping, I confirm it passes before (jdk9 or jdk10 before patch). To ensure it detects any regression, I manually inserted some bugs in the clipping code, and the test failed. Note: I should add another test @run to check the float variant too (and not only the double variant, the default in jdk10). Finally I could write a new performance test that would prove clipping is more efficient than before. Such test would fail before patch (timeout ?), but it is difficult to make it robust as it depends on the hw. Jim wrote a basic test in the jfx bug showing 300ms without but 2ms now => gain is high. A possible success condition would be: clipping gain > 10 or 50. Regards, Laurent Le 4 d?c. 2017 11:11 PM, "Sergey Bylokhov" a ?crit : Hi, Laurent. On 29/11/2017 14:30, Laurent Bourg?s wrote: > - added new ClipShapeTest (jtreg) that checks all possible combinations of > (cap / join) for random polyline (Stroker) and polygons (Filler) comparing > image outputs rendered with clipping enabled vs disabled > I have only one note that the test is passed before the fix, so if we will regress at some point later we will not catch this. -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Tue Dec 5 14:30:50 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Tue, 5 Dec 2017 15:30:50 +0100 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip In-Reply-To: References: Message-ID: Hi again, Here is a new webrev fixing the ClipShapeTest: http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8191814.1/ Changes: - @run twice to test both Marlin variants (float / double) - use Logger to get & check marlin system properties ("sun.java2d.renderer.clip.runtime.enable") to ensure the test is run against a Marlin renderer having the clipping features I tested the fixed test on JDK9 and it fails: runner finished test: sun/java2d/marlin/ClipShapeTest.java Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Marlin clipping not enabled at runtime ! On JDK10 + patch, it passes: sun/java2d/marlin/ClipShapeTest.java Passed. Execution successful PS: Could anyone review the patch ? before RDP1 deadline ? Regards, Laurent 2017-12-04 23:35 GMT+01:00 Laurent Bourg?s : > Hi Sergey, > > Thanks for your comment. > > This new test only validates the new clipping algorithms ie it compares > the rendering outputs with / without clipping enabled. > > As such algorithms are only available in Marlin 0.8.2 and the test uses > new system properties to enable/disable clipping, I confirm it passes > before (jdk9 or jdk10 before patch). > > To ensure it detects any regression, I manually inserted some bugs in the > clipping code, and the test failed. > > Note: I should add another test @run to check the float variant too (and > not only the double variant, the default in jdk10). > > Finally I could write a new performance test that would prove clipping is > more efficient than before. > Such test would fail before patch (timeout ?), but it is difficult to make > it robust as it depends on the hw. > Jim wrote a basic test in the jfx bug showing 300ms without but 2ms now => > gain is high. > A possible success condition would be: clipping gain > 10 or 50. > > Regards, > Laurent > > > Le 4 d?c. 2017 11:11 PM, "Sergey Bylokhov" a > ?crit : > > Hi, Laurent. > > On 29/11/2017 14:30, Laurent Bourg?s wrote: > >> - added new ClipShapeTest (jtreg) that checks all possible combinations >> of (cap / join) for random polyline (Stroker) and polygons (Filler) >> comparing image outputs rendered with clipping enabled vs disabled >> > > I have only one note that the test is passed before the fix, so if we will > regress at some point later we will not catch this. > > > -- > Best regards, Sergey. > > > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Dec 7 15:16:56 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 7 Dec 2017 07:16:56 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Message-ID: Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or X11 we don't see any issue. Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Dec 7 19:43:24 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 7 Dec 2017 11:43:24 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip In-Reply-To: References: Message-ID: I am not an expert here, I just look to the changes and run the closed tests for jdk_desktop group. No new issues were found, so it looks fine to me. On 05/12/2017 06:30, Laurent Bourg?s wrote: > Hi again, > > Here is a new webrev fixing the ClipShapeTest: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8191814.1/ > > Changes: > - @run twice to test both Marlin variants (float / double) > - use Logger to get & check marlin system properties > ("sun.java2d.renderer.clip.runtime.enable") to ensure the test is run > against a Marlin renderer having the clipping features > > I tested the fixed test on JDK9 and it fails: > runner finished test: sun/java2d/marlin/ClipShapeTest.java > Failed. Execution failed: `main' threw exception: > java.lang.RuntimeException: Marlin clipping not enabled at runtime ! > > On JDK10 + patch, it passes: > sun/java2d/marlin/ClipShapeTest.java > Passed. Execution successful > > > PS: Could anyone review the patch ? before RDP1 deadline ? > > Regards, > Laurent > > > 2017-12-04 23:35 GMT+01:00 Laurent Bourg?s >: > > Hi Sergey, > > Thanks for your comment. > > This new test only validates the new clipping algorithms ie it > compares the rendering outputs with / without clipping enabled. > > As such algorithms are only available in Marlin 0.8.2 and the test > uses new system properties to enable/disable clipping, I confirm it > passes before (jdk9 or jdk10 before patch). > > To ensure it detects any regression, I manually inserted some bugs > in the clipping code, and the test failed. > > Note: I should add another test @run to check the float variant too > (and not only the double variant, the default in jdk10). > > Finally I could write a new performance test that would prove > clipping is more efficient than before. > Such test would fail before patch (timeout ?), but it is difficult > to make it robust as it depends on the hw. > Jim wrote a basic test in the jfx bug showing 300ms without but 2ms > now => gain is high. > A possible success condition would be: clipping gain > 10 or 50. > > Regards, > Laurent > > > Le?4 d?c. 2017 11:11 PM, "Sergey Bylokhov" > > a > ?crit?: > > Hi, Laurent. > > On 29/11/2017 14:30, Laurent Bourg?s wrote: > > - added new ClipShapeTest (jtreg) that checks all possible > combinations of (cap / join) for random polyline (Stroker) > and polygons (Filler) comparing image outputs rendered with > clipping enabled vs disabled > > > I have only one note that the test is passed before the fix, so > if we will regress at some point later we will not catch this. > > > -- > Best regards, Sergey. > > > > > > -- > -- > Laurent Bourg?s -- Best regards, Sergey. From philip.race at oracle.com Thu Dec 7 20:54:14 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 7 Dec 2017 12:54:14 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. Message-ID: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809 webrev: http://cr.openjdk.java.net/~prr/8189809/ This partially addresses a slow-down in Swing. Swing now usually calls Font.getStringBounds() instead of FontMetrics().stringWidth for text measurement. The latter has a fast-path for latin-only simple text. The former does not .. and at a minimum uses GlyphVector. This fix provides a similar fast path and for direct calls to these methods (micro benchmarks) that is latin text they are now very similar .. at least for typical strings. In this fix as well as making this change in the font code, I updated Swing to more be a little more efficient. Before this fix I always saw Swing coming in with a char[] .. then constructing a String from it. Then it passes it to the font measurement code, which then decomposes the string back into a char[] If Swing directly uses the API that takes a char[] then we save some overhead. It does not get back all of the loss by Swing since 1) Swing has other overhead elsewhere - it seems 2) Swing is making 90% of these calls for a single char. This could be from where Swing naively tries to add up char advances itself to get a string advance. We may have to come back to that later. Perhaps with new public API. -phil. From philip.race at oracle.com Sun Dec 10 17:36:22 2017 From: philip.race at oracle.com (Philip Race) Date: Sun, 10 Dec 2017 09:36:22 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <8cf1adc7-391c-410f-8d9c-9b6389251b9d@oracle.com> Message-ID: <5A2D7096.9080703@oracle.com> I'm giving this an OK. I've looked at the code, if not the maths, and run our regression test suite. I had a bit of trouble with my full baseline run against which to compare so I've re-run just the test failures that seem like they might go anywhere need this code. and they were pre-existing. -phil. On 11/16/17, 3:01 PM, Laurent Bourg?s wrote: > Phil, > > Here is an updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/ > > > It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 test > setups only (5000 random polygons each) that covers all aspects of the > new clipping algorithm. > > I wonder if I should remove the 'slow' mode that has till @ignore: > both tests are ignored if I run jtreg -ignore:quiet although I would > like to only ignore the @ignore run (1/2). > > > Once again, I have to create a new JBS bug for Marlin2D tomorrow then > start a new RFR with a complete change log. > > Laurent > > 2017-11-16 10:50 GMT+01:00 Laurent Bourg?s >: > > Sergey, > > You can generate a number of images using a few threads when > the flag is on then switch it off and compares results. The > test should not draw different(on/off) modes in parallel but > it can draw the images for the same mode. > > > Yes that is always possible but I do not want to spend too much > time improving the test to parallelize it. > > I fixed it last night and it runs only 22 test setups (1 stroke > width = 8px, no dashes) and takes ~ 30 seconds on my laptop > (single-thread). > I verified that any bug in Marlin clipping is detected by this new > variant of the tests. > Will provide a new patch asap. > > > Finally I will minimize the number of stroker tests: use > only 1 stroke width (=5px) and that should be enough to > stay below timeout (2mins). > > > Note that the test can be run on some slow/virtual systems, it > would be good to have some additional time. > > Is there any documentation about jtreg tags ? > > > You can find it here: > http://openjdk.java.net/jtreg/tag-spec.html > > > > Thanks. > > Laurent > > > > > -- > -- > Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Sun Dec 10 20:39:03 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Sun, 10 Dec 2017 21:39:03 +0100 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <5A2D7096.9080703@oracle.com> References: <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <8cf1adc7-391c-410f-8d9c-9b6389251b9d@oracle.com> <5A2D7096.9080703@oracle.com> Message-ID: Phil, Thanks for your review. I suppose you approved the Java2D patch for the RFR thread: [10] RFR JDK-8191814: http://mail.openjdk.java.net/pipermail/2d-dev/2017-November/008741.html I will push tomorrow to jdk forrest as phil & sergey? approved 2D changes. This RFR thread remains open for the JavaFX patch that Kevin started to test & review. Cheers, Laurent 2017-12-10 18:36 GMT+01:00 Philip Race : > I'm giving this an OK. > I've looked at the code, if not the maths, and run our regression test > suite. > I had a bit of trouble with my full baseline run against which to compare > so I've > re-run just the test failures that seem like they might go anywhere need > this code. > and they were pre-existing. > > -phil. > > > On 11/16/17, 3:01 PM, Laurent Bourg?s wrote: > > Phil, > > Here is an updated webrev: > http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/ > > It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 test > setups only (5000 random polygons each) that covers all aspects of the new > clipping algorithm. > > I wonder if I should remove the 'slow' mode that has till @ignore: > both tests are ignored if I run jtreg -ignore:quiet although I would like > to only ignore the @ignore run (1/2). > > > Once again, I have to create a new JBS bug for Marlin2D tomorrow then > start a new RFR with a complete change log. > > Laurent > > 2017-11-16 10:50 GMT+01:00 Laurent Bourg?s : > >> Sergey, >> >> You can generate a number of images using a few threads when the flag is >>> on then switch it off and compares results. The test should not draw >>> different(on/off) modes in parallel but it can draw the images for the same >>> mode. >>> >> >> Yes that is always possible but I do not want to spend too much time >> improving the test to parallelize it. >> >> I fixed it last night and it runs only 22 test setups (1 stroke width = >> 8px, no dashes) and takes ~ 30 seconds on my laptop (single-thread). >> I verified that any bug in Marlin clipping is detected by this new >> variant of the tests. >> Will provide a new patch asap. >> >> >>> >>> Finally I will minimize the number of stroker tests: use only 1 stroke >>>> width (=5px) and that should be enough to stay below timeout (2mins). >>>> >>> >>> Note that the test can be run on some slow/virtual systems, it would be >>> good to have some additional time. >>> >>> Is there any documentation about jtreg tags ? >>>> >>> >>> You can find it here: >>> http://openjdk.java.net/jtreg/tag-spec.html >>> >> >> Thanks. >> >> Laurent >> > > > > -- > -- > Laurent Bourg?s > > -- -- Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Dec 11 11:12:27 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 11 Dec 2017 03:12:27 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: References: Message-ID: Hello All, Gentle reminder for review. Thanks, Jay From: Jayathirth D V Sent: Thursday, December 07, 2017 8:47 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or X11 we don't see any issue. Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Mon Dec 11 13:10:48 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 11 Dec 2017 05:10:48 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. In-Reply-To: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> Message-ID: <332230c2-15b6-4101-b078-74c1ea906e3f@default> Hello Phil The change looks good to me. I found two interesting changes in your webrev. . The move to use FontDesignMetrics to compute width should be better than generating GlyphVector for the same. . Besides, the double conversion from chars[] to String and vice versa has been avoided as well. Thank you Have a good day Prahalad -----Original Message----- From: Phil Race Sent: Friday, December 08, 2017 2:24 AM To: 2d-dev; swing-dev at openjdk.java.net Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. Bug: https://bugs.openjdk.java.net/browse/JDK-8189809 webrev: http://cr.openjdk.java.net/~prr/8189809/ This partially addresses a slow-down in Swing. Swing now usually calls Font.getStringBounds() instead of FontMetrics().stringWidth for text measurement. The latter has a fast-path for latin-only simple text. The former does not .. and at a minimum uses GlyphVector. This fix provides a similar fast path and for direct calls to these methods (micro benchmarks) that is latin text they are now very similar .. at least for typical strings. In this fix as well as making this change in the font code, I updated Swing to more be a little more efficient. Before this fix I always saw Swing coming in with a char[] .. then constructing a String from it. Then it passes it to the font measurement code, which then decomposes the string back into a char[] If Swing directly uses the API that takes a char[] then we save some overhead. It does not get back all of the loss by Swing since 1) Swing has other overhead elsewhere - it seems 2) Swing is making 90% of these calls for a single char. This could be from where Swing naively tries to add up char advances itself to get a string advance. We may have to come back to that later. Perhaps with new public API. -phil. From philip.race at oracle.com Mon Dec 11 17:05:55 2017 From: philip.race at oracle.com (Philip Race) Date: Mon, 11 Dec 2017 09:05:55 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: References: <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <8cf1adc7-391c-410f-8d9c-9b6389251b9d@oracle.com> <5A2D7096.9080703@oracle.com> Message-ID: <5A2EBAF3.9080003@oracle.com> Yes, I approved the 2D patch. I have not yet looked at the FX version. -phil On 12/10/17, 12:39 PM, Laurent Bourg?s wrote: > Phil, > > Thanks for your review. > > I suppose you approved the Java2D patch for the RFR thread: [10] RFR > JDK-8191814: > http://mail.openjdk.java.net/pipermail/2d-dev/2017-November/008741.html > > I will push tomorrow to jdk forrest as phil & sergey? approved 2D changes. > > > This RFR thread remains open for the JavaFX patch that Kevin started > to test & review. > > Cheers, > Laurent > > 2017-12-10 18:36 GMT+01:00 Philip Race >: > > I'm giving this an OK. > I've looked at the code, if not the maths, and run our regression > test suite. > I had a bit of trouble with my full baseline run against which to > compare so I've > re-run just the test failures that seem like they might go > anywhere need this code. > and they were pre-existing. > > -phil. > > > On 11/16/17, 3:01 PM, Laurent Bourg?s wrote: >> Phil, >> >> Here is an updated webrev: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/ >> >> >> It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 >> test setups only (5000 random polygons each) that covers all >> aspects of the new clipping algorithm. >> >> I wonder if I should remove the 'slow' mode that has till @ignore: >> both tests are ignored if I run jtreg -ignore:quiet although I >> would like to only ignore the @ignore run (1/2). >> >> >> Once again, I have to create a new JBS bug for Marlin2D tomorrow >> then start a new RFR with a complete change log. >> >> Laurent >> >> 2017-11-16 10:50 GMT+01:00 Laurent Bourg?s >> >: >> >> Sergey, >> >> You can generate a number of images using a few threads >> when the flag is on then switch it off and compares >> results. The test should not draw different(on/off) modes >> in parallel but it can draw the images for the same mode. >> >> >> Yes that is always possible but I do not want to spend too >> much time improving the test to parallelize it. >> >> I fixed it last night and it runs only 22 test setups (1 >> stroke width = 8px, no dashes) and takes ~ 30 seconds on my >> laptop (single-thread). >> I verified that any bug in Marlin clipping is detected by >> this new variant of the tests. >> Will provide a new patch asap. >> >> >> Finally I will minimize the number of stroker tests: >> use only 1 stroke width (=5px) and that should be >> enough to stay below timeout (2mins). >> >> >> Note that the test can be run on some slow/virtual >> systems, it would be good to have some additional time. >> >> Is there any documentation about jtreg tags ? >> >> >> You can find it here: >> http://openjdk.java.net/jtreg/tag-spec.html >> >> >> >> Thanks. >> >> Laurent >> >> >> >> >> -- >> -- >> Laurent Bourg?s > > > > > -- > -- > Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.rushforth at oracle.com Mon Dec 11 17:13:06 2017 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 11 Dec 2017 09:13:06 -0800 Subject: [OpenJDK 2D-Dev] RFR JDK-8184429: Path clipper added in Marlin2D & MarlinFX 0.8.0 In-Reply-To: <5A2EBAF3.9080003@oracle.com> References: <59B004BF.2000105@oracle.com> <018f1daa-d154-9d97-88f7-93bc0a376293@oracle.com> <8cf1adc7-391c-410f-8d9c-9b6389251b9d@oracle.com> <5A2D7096.9080703@oracle.com> <5A2EBAF3.9080003@oracle.com> Message-ID: <5A2EBCA2.5010000@oracle.com> I started looking the FX patch on Friday. I hope to finish my review today. -- Kevin Philip Race wrote: > Yes, I approved the 2D patch. I have not yet looked at the FX version. > > -phil > > On 12/10/17, 12:39 PM, Laurent Bourg?s wrote: >> Phil, >> >> Thanks for your review. >> >> I suppose you approved the Java2D patch for the RFR thread: [10] RFR >> JDK-8191814: >> http://mail.openjdk.java.net/pipermail/2d-dev/2017-November/008741.html >> >> I will push tomorrow to jdk forrest as phil & sergey? approved 2D >> changes. >> >> >> This RFR thread remains open for the JavaFX patch that Kevin started >> to test & review. >> >> Cheers, >> Laurent >> >> 2017-12-10 18:36 GMT+01:00 Philip Race > >: >> >> I'm giving this an OK. >> I've looked at the code, if not the maths, and run our regression >> test suite. >> I had a bit of trouble with my full baseline run against which to >> compare so I've >> re-run just the test failures that seem like they might go >> anywhere need this code. >> and they were pre-existing. >> >> -phil. >> >> >> On 11/16/17, 3:01 PM, Laurent Bourg?s wrote: >>> Phil, >>> >>> Here is an updated webrev: >>> http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8184429.1/ >>> >>> >>> It fixes the ClipShapeTest to run ~35s (< 2mins) on my latop: 22 >>> test setups only (5000 random polygons each) that covers all >>> aspects of the new clipping algorithm. >>> >>> I wonder if I should remove the 'slow' mode that has till @ignore: >>> both tests are ignored if I run jtreg -ignore:quiet although I >>> would like to only ignore the @ignore run (1/2). >>> >>> >>> Once again, I have to create a new JBS bug for Marlin2D tomorrow >>> then start a new RFR with a complete change log. >>> >>> Laurent >>> >>> 2017-11-16 10:50 GMT+01:00 Laurent Bourg?s >>> >: >>> >>> Sergey, >>> >>> You can generate a number of images using a few threads >>> when the flag is on then switch it off and compares >>> results. The test should not draw different(on/off) >>> modes in parallel but it can draw the images for the >>> same mode. >>> >>> >>> Yes that is always possible but I do not want to spend too >>> much time improving the test to parallelize it. >>> >>> I fixed it last night and it runs only 22 test setups (1 >>> stroke width = 8px, no dashes) and takes ~ 30 seconds on my >>> laptop (single-thread). >>> I verified that any bug in Marlin clipping is detected by >>> this new variant of the tests. >>> Will provide a new patch asap. >>> >>> >>> >>> Finally I will minimize the number of stroker tests: >>> use only 1 stroke width (=5px) and that should be >>> enough to stay below timeout (2mins). >>> >>> >>> Note that the test can be run on some slow/virtual >>> systems, it would be good to have some additional time. >>> >>> Is there any documentation about jtreg tags ? >>> >>> >>> You can find it here: >>> http://openjdk.java.net/jtreg/tag-spec.html >>> >>> >>> >>> Thanks. >>> >>> Laurent >>> >>> >>> >>> >>> -- >>> -- >>> Laurent Bourg?s >> >> >> >> >> -- >> -- >> Laurent Bourg?s -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Dec 11 18:45:27 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Dec 2017 10:45:27 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: References: Message-ID: The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 > > Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ > > > Issue : When we draw translucent color over an opaque color in Unix > from JDK 8 we get different color after composition compared to any > other platform. > > Root cause : From JDK 8, X Rendering extension is enabled in Unix and > we see this problem only when we use XRender in Unix if we use GLX or > X11 we don?t see any issue. Also X Rendering extension expects > pre-multiplied alpha color values, so we need to convert the > non-premultiplied alpha color values to pre-multiplied alpha color > values before give pixel value to XRender for drawing. The main > problem is we do this operation of conversion twice: > > 1)When we call Graphics2D.setColor() it uses ArgbPre PixelConverter > based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and > converts the color to pre-multiplied values. > > 2)When we call Graphics2D.fillRect() internally before we compose the > destination(opaque color) and source(translucent color) we prepare > source render rectangle for X Render extension. Here again we convert > the already converted color values to premultiplied values. > > Solution : There is no need for us to do non-pre to pre color > conversion again at XRender level so it should be removed. Also this > logic of non-pre to pre color conversion at XRender was only used when > source is Solid color and not Texture/Gradient. So I have completely > removed this logic itself as it not needed anywhere else. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Mon Dec 11 20:32:19 2017 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Mon, 11 Dec 2017 21:32:19 +0100 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8191814: Marlin rasterizer spends time computing geometry for stroked segments that do not intersect the clip In-Reply-To: References: Message-ID: Hi, I pushed in jdk forrest: http://hg.openjdk.java.net/jdk/client/rev/fd7fbc929001 Thanks for your reviews, Phil & Sergey ! Laurent 2017-12-07 20:43 GMT+01:00 Sergey Bylokhov : > I am not an expert here, I just look to the changes and run the closed > tests for jdk_desktop group. No new issues were found, so it looks fine to > me. > > On 05/12/2017 06:30, Laurent Bourg?s wrote: > >> Hi again, >> >> Here is a new webrev fixing the ClipShapeTest: >> http://cr.openjdk.java.net/~lbourges/marlin/marlin-082-8191814.1/ >> >> Changes: >> - @run twice to test both Marlin variants (float / double) >> - use Logger to get & check marlin system properties >> ("sun.java2d.renderer.clip.runtime.enable") to ensure the test is run >> against a Marlin renderer having the clipping features >> >> I tested the fixed test on JDK9 and it fails: >> runner finished test: sun/java2d/marlin/ClipShapeTest.java >> Failed. Execution failed: `main' threw exception: >> java.lang.RuntimeException: Marlin clipping not enabled at runtime ! >> >> On JDK10 + patch, it passes: >> sun/java2d/marlin/ClipShapeTest.java >> Passed. Execution successful >> >> >> PS: Could anyone review the patch ? before RDP1 deadline ? >> >> Regards, >> Laurent >> >> >> 2017-12-04 23:35 GMT+01:00 Laurent Bourg?s > >: >> >> Hi Sergey, >> >> Thanks for your comment. >> >> This new test only validates the new clipping algorithms ie it >> compares the rendering outputs with / without clipping enabled. >> >> As such algorithms are only available in Marlin 0.8.2 and the test >> uses new system properties to enable/disable clipping, I confirm it >> passes before (jdk9 or jdk10 before patch). >> >> To ensure it detects any regression, I manually inserted some bugs >> in the clipping code, and the test failed. >> >> Note: I should add another test @run to check the float variant too >> (and not only the double variant, the default in jdk10). >> >> Finally I could write a new performance test that would prove >> clipping is more efficient than before. >> Such test would fail before patch (timeout ?), but it is difficult >> to make it robust as it depends on the hw. >> Jim wrote a basic test in the jfx bug showing 300ms without but 2ms >> now => gain is high. >> A possible success condition would be: clipping gain > 10 or 50. >> >> Regards, >> Laurent >> >> >> Le 4 d?c. 2017 11:11 PM, "Sergey Bylokhov" >> > a >> ?crit : >> >> Hi, Laurent. >> >> On 29/11/2017 14:30, Laurent Bourg?s wrote: >> >> - added new ClipShapeTest (jtreg) that checks all possible >> combinations of (cap / join) for random polyline (Stroker) >> and polygons (Filler) comparing image outputs rendered with >> clipping enabled vs disabled >> >> >> I have only one note that the test is passed before the fix, so >> if we will regress at some point later we will not catch this. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Dec 11 22:12:21 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Dec 2017 14:12:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. In-Reply-To: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> Message-ID: <3f728086-7545-b844-7ee4-8735593c0136@oracle.com> Hi, Phil. The new code will calculate the logical bounds this way: 541 new Rectangle2D.Float(0f, ascent, width, height); But previously it was: 2613 new Rectangle2D.Float(0, -tl.getAscent(), tl.getAdvance(), 2614 tl.getAscent() + tl.getDescent() + 2615 tl.getLeading()); Note that the second parameter is negative, is it intentionally changed? On 07/12/2017 12:54, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8189809 > webrev: http://cr.openjdk.java.net/~prr/8189809/ > > This partially addresses a slow-down in Swing. > > Swing now usually calls Font.getStringBounds() instead of > FontMetrics().stringWidth for text measurement. > > The latter has a fast-path for latin-only simple text. > > The former does not .. and at a minimum uses GlyphVector. > > This fix provides a similar fast path and for direct calls to these > methods (micro benchmarks) > that is latin text they are now very similar .. at least for typical > strings. > > In this fix as well as making this change in the font code, I updated > Swing to more > be a little more efficient. > > Before this fix I always saw Swing? coming in with a char[] .. then > constructing a String from it. > Then it passes it to the font measurement code, which then decomposes > the string back into a char[] > If Swing directly uses the API that takes a char[] then we save some > overhead. > > > It does not get back all of the loss by Swing since > > 1) Swing has other overhead elsewhere - it seems > > 2) Swing is making 90% of these calls for a single char. > This could be from where Swing naively tries to add up char advances > itself to > get a string advance. > > ??? We may have to come back to that later. Perhaps with new public API. > > -phil. > > -- Best regards, Sergey. From philip.race at oracle.com Mon Dec 11 22:39:54 2017 From: philip.race at oracle.com (Phil Race) Date: Mon, 11 Dec 2017 14:39:54 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. In-Reply-To: <3f728086-7545-b844-7ee4-8735593c0136@oracle.com> References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> <3f728086-7545-b844-7ee4-8735593c0136@oracle.com> Message-ID: Yes, it should be negative since we want to use this as the y origin of the rectangle relative to the baseline. I am using it correctly in the height calculation. 40 float height = ascent + descent + leading; 541 return new Rectangle2D.Float(0f, ascent, width, height); http://cr.openjdk.java.net/~prr/8189809.1/ -phil. On 12/11/2017 02:12 PM, Sergey Bylokhov wrote: > Hi, Phil. > The new code will calculate the logical bounds this way: > 541 new Rectangle2D.Float(0f, ascent, width, height); > But previously it was: > 2613 new Rectangle2D.Float(0, -tl.getAscent(), tl.getAdvance(), > 2614 tl.getAscent() + tl.getDescent() + > 2615 tl.getLeading()); > > Note that the second parameter is negative, is it intentionally changed? > > > On 07/12/2017 12:54, Phil Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809 >> webrev: http://cr.openjdk.java.net/~prr/8189809/ >> >> This partially addresses a slow-down in Swing. >> >> Swing now usually calls Font.getStringBounds() instead of >> FontMetrics().stringWidth for text measurement. >> >> The latter has a fast-path for latin-only simple text. >> >> The former does not .. and at a minimum uses GlyphVector. >> >> This fix provides a similar fast path and for direct calls to these >> methods (micro benchmarks) >> that is latin text they are now very similar .. at least for typical >> strings. >> >> In this fix as well as making this change in the font code, I updated >> Swing to more >> be a little more efficient. >> >> Before this fix I always saw Swing coming in with a char[] .. then >> constructing a String from it. >> Then it passes it to the font measurement code, which then decomposes >> the string back into a char[] >> If Swing directly uses the API that takes a char[] then we save some >> overhead. >> >> >> It does not get back all of the loss by Swing since >> >> 1) Swing has other overhead elsewhere - it seems >> >> 2) Swing is making 90% of these calls for a single char. >> This could be from where Swing naively tries to add up char advances >> itself to >> get a string advance. >> >> We may have to come back to that later. Perhaps with new public >> API. >> >> -phil. >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Dec 11 22:56:02 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 11 Dec 2017 14:56:02 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8189809: Large performance regression in Swing text layout. In-Reply-To: References: <3afdaac9-4ce3-661d-d6d6-5efc25e4bfb6@oracle.com> <3f728086-7545-b844-7ee4-8735593c0136@oracle.com> Message-ID: <41ed31d9-8959-28d7-818a-a892a078eef6@oracle.com> Looks fine. On 11/12/2017 14:39, Phil Race wrote: > Yes, it should? be negative since we want to use this as the y origin of > the rectangle > relative to the baseline. I am using it correctly in the height calculation. > > 40 float height = ascent + descent + leading; > 541 return new Rectangle2D.Float(0f, ascent, width, height); > > > http://cr.openjdk.java.net/~prr/8189809.1/ > > -phil. > > On 12/11/2017 02:12 PM, Sergey Bylokhov wrote: >> Hi, Phil. >> The new code will calculate the logical bounds this way: >> ??? 541 new Rectangle2D.Float(0f, ascent, width, height); >> But previously it was: >> ??? 2613 new Rectangle2D.Float(0, -tl.getAscent(), tl.getAdvance(), >> ??? 2614?????????????????????? tl.getAscent() + tl.getDescent() + >> ??? 2615?????????????????????? tl.getLeading()); >> >> Note that the second parameter is negative, is it intentionally changed? >> >> >> On 07/12/2017 12:54, Phil Race wrote: >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189809 >>> webrev: http://cr.openjdk.java.net/~prr/8189809/ >>> >>> This partially addresses a slow-down in Swing. >>> >>> Swing now usually calls Font.getStringBounds() instead of >>> FontMetrics().stringWidth for text measurement. >>> >>> The latter has a fast-path for latin-only simple text. >>> >>> The former does not .. and at a minimum uses GlyphVector. >>> >>> This fix provides a similar fast path and for direct calls to these >>> methods (micro benchmarks) >>> that is latin text they are now very similar .. at least for typical >>> strings. >>> >>> In this fix as well as making this change in the font code, I updated >>> Swing to more >>> be a little more efficient. >>> >>> Before this fix I always saw Swing? coming in with a char[] .. then >>> constructing a String from it. >>> Then it passes it to the font measurement code, which then decomposes >>> the string back into a char[] >>> If Swing directly uses the API that takes a char[] then we save some >>> overhead. >>> >>> >>> It does not get back all of the loss by Swing since >>> >>> 1) Swing has other overhead elsewhere - it seems >>> >>> 2) Swing is making 90% of these calls for a single char. >>> This could be from where Swing naively tries to add up char advances >>> itself to >>> get a string advance. >>> >>> ???? We may have to come back to that later. Perhaps with new public >>> API. >>> >>> -phil. >>> >>> >> >> > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Wed Dec 13 09:32:07 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Dec 2017 01:32:07 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Message-ID: Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Wed Dec 13 09:58:47 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 13 Dec 2017 01:58:47 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: Message-ID: Hello Jay I looked into the changes. The logic to check the presence of PLTE chunk is correct. Few minor changes . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. . You can move the if condition within the if block that stores location of 1st IDAT chunk. . Secondly, the wording within the IIOException can be changed. . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Wednesday, December 13, 2017 3:02 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. Thanks, Jay From jayathirth.d.v at oracle.com Wed Dec 13 10:50:10 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Dec 2017 02:50:10 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: Message-ID: Hello Prahalad, Thanks for your inputs. I have updated the code based on your inputs. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Wednesday, December 13, 2017 3:29 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Hello Jay I looked into the changes. The logic to check the presence of PLTE chunk is correct. Few minor changes . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. . You can move the if condition within the if block that stores location of 1st IDAT chunk. . Secondly, the wording within the IIOException can be changed. . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Wednesday, December 13, 2017 3:02 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Hello All, Please review the following fix in JDK10 : Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. Thanks, Jay From Sergey.Bylokhov at oracle.com Wed Dec 13 16:05:11 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 13 Dec 2017 08:05:11 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: Message-ID: It looks fine, but I wonder why metadata.PLTE_present == false is used instead of !metadata.PLTE_present On 13/12/2017 02:50, Jayathirth D V wrote: > Hello Prahalad, > > Thanks for your inputs. > I have updated the code based on your inputs. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, December 13, 2017 3:29 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello Jay > > I looked into the changes. > The logic to check the presence of PLTE chunk is correct. > > Few minor changes > . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. > . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. > . You can move the if condition within the if block that stores location of 1st IDAT chunk. > > . Secondly, the wording within the IIOException can be changed. > . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. > . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Wednesday, December 13, 2017 3:02 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 > Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ > > Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. > > Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. > > Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. > > Thanks, > Jay > -- Best regards, Sergey. From jayathirth.d.v at oracle.com Thu Dec 14 04:17:04 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 13 Dec 2017 20:17:04 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: Message-ID: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> Hello Sergey, Thanks for your inputs. Comparison using == just comes out of me because of my coding style. Since the variable name PLTE_present is self-explanatory that it is of type boolean I also feel from verbose perspective we should use ! operator. I have updated the code to reflect the same. Apart from verbose perspective is there anything different in Java between using == & ! in this case. Please provide your inputs as it would be helpful in future changes. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8190997/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, December 13, 2017 9:35 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing It looks fine, but I wonder why metadata.PLTE_present == false is used instead of !metadata.PLTE_present On 13/12/2017 02:50, Jayathirth D V wrote: > Hello Prahalad, > > Thanks for your inputs. > I have updated the code based on your inputs. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, December 13, 2017 3:29 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello Jay > > I looked into the changes. > The logic to check the presence of PLTE chunk is correct. > > Few minor changes > . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. > . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. > . You can move the if condition within the if block that stores location of 1st IDAT chunk. > > . Secondly, the wording within the IIOException can be changed. > . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. > . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Wednesday, December 13, 2017 3:02 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 > Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ > > Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. > > Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. > > Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. > > Thanks, > Jay > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Thu Dec 14 04:52:01 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Wed, 13 Dec 2017 20:52:01 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> References: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> Message-ID: <791407e0-2f89-4667-ade4-17eac05c799e@default> Hello Jay The fix looks good. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, December 14, 2017 9:47 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Hello Sergey, Thanks for your inputs. Comparison using == just comes out of me because of my coding style. Since the variable name PLTE_present is self-explanatory that it is of type boolean I also feel from verbose perspective we should use ! operator. I have updated the code to reflect the same. Apart from verbose perspective is there anything different in Java between using == & ! in this case. Please provide your inputs as it would be helpful in future changes. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8190997/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, December 13, 2017 9:35 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing It looks fine, but I wonder why metadata.PLTE_present == false is used instead of !metadata.PLTE_present On 13/12/2017 02:50, Jayathirth D V wrote: > Hello Prahalad, > > Thanks for your inputs. > I have updated the code based on your inputs. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, December 13, 2017 3:29 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello Jay > > I looked into the changes. > The logic to check the presence of PLTE chunk is correct. > > Few minor changes > . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. > . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. > . You can move the if condition within the if block that stores location of 1st IDAT chunk. > > . Secondly, the wording within the IIOException can be changed. > . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. > . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Wednesday, December 13, 2017 3:02 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 > Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ > > Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. > > Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. > > Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. > > Thanks, > Jay > -- Best regards, Sergey. From dmitry.batrak at jetbrains.com Thu Dec 14 08:21:34 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 14 Dec 2017 11:21:34 +0300 Subject: [OpenJDK 2D-Dev] Problems logging in to http://bugs.openjdk.java.net Message-ID: Hello, I'm sorry to bother you with this, but I regularly have problems logging in to OpenJDK issue tracker (bugs.openjdk.java.net). I reported this to help at openjdk.java.net ('Contact Us' link on log-in page) more than 3 months ago but got no response. I also couldn't find a suitable mailing list for this question at http://mail.openjdk.java.net/mailman/listinfo. Maybe someone on this list can suggest who can I address this to. For completeness, below is the description of the problem: I use 'Log In' link in the top right corner of the website. In the opened OpenJDK Log In page I enter my email (Dmitry.Batrak at jetbrains.com) and password. After pressing 'Log In' button I'm redirected to the original bugs.openjdk.java.net page, but I'm still not logged in (Log In link is still displayed in the top right corner). I'm sure I'm entering my password correctly, because if I try a definitely wrong password I get a specific notification about it. Sometimes it works, but it can take tens of attempts to make it work. -- Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Dec 14 08:18:01 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Dec 2017 00:18:01 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Message-ID: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> Hello All, Please review the following fix in JDK : Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". Exception in thread "main" java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride at java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelInterleavedSampleModel.java:101) at java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java:642) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(PNGImageReader.java:974) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1099) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1295) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1420) at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1699) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) at PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java:50) Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8190332"JDK-8190332 and not the undocumented IllegalArgumentException. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Thu Dec 14 11:49:16 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 14 Dec 2017 03:49:16 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: References: Message-ID: Hello Jay I looked into the changes. Here are my views. > X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. > The main problem is we do this operation of conversion twice . Your observation is correct. This is a good find. . The double conversion occurs because of mis-match between two objects - . XRCompositeManager that passes pre-multiplied alpha color to prepare XRSolidSrcPict and . XRSolidSrcPict that expects a "non pre-multiplied" alpha color in its prepareSrcPict method. > Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. > So I have completely removed this logic itself as it not needed anywhere else. . In the proposed fix, you have removed a convenience logic in XRColor.java and modified one (XRColor) method signature as well. . In my view, this change is not required at all. Reasons are- . Though the convenience logic isn't used presently, it could definitely come handy in future whenever a need arises. . The change to method's signature has resulted in recursive changes in many other files as well. . The bug and the fix are not related to XRColor object in general. Combining the above observation, the fix would be to correct 2nd argument of below mentioned line from "false" to "true". Thus retain the convenience logic in XRColor.java as well. File: XRSolidSrcPict.java line 50 xrCol.setColorValues(pixelVal, false); // Change false to true Btw, the test case involves drawing on a VolatileImage & getting its snapshot. But it doesn't check if the created volatile image is valid for a particular Graphics configuration before invoking any drawing operation. You could refer to one of the existing test cases and correct the test file. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Phil Race Sent: Tuesday, December 12, 2017 12:15 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: Hello All, ? Please review the following fix in JDK10 : ? Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ ? Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. ? Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or ?X11 we don't see any issue. ?Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. ? Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. ? Thanks, Jay ? From jayathirth.d.v at oracle.com Thu Dec 14 13:18:48 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 14 Dec 2017 05:18:48 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. In-Reply-To: References: Message-ID: <294c9548-0095-4b68-bb6b-1c8d0eba2cc1@default> Hello Prahalad, Thanks for your inputs. Regarding code change mentioned by you in source: Initially I also just replaced xrCol.setColorValues(pixelVal, false) with xrCol.setColorValues(pixelVal, true) in XRSolidSrcPict.java to fix the issue. After that I listed call hierarchy to XRColor.setColorValues(int, boolean) and found that after my fix at all the places we are passing second argument as true and it is resulting in dead/unused code in XRColor.setColorValues(int, boolean). Dead code in XRColor.setColorValues(int, boolean) which will be never reached: if (!pre) { double alphaMult = XRUtils.XFixedToDouble(alpha); this.red = (int) (red * alphaMult); this.green = (int) (green * alphaMult); this.blue = (int) (blue * alphaMult); } Before removing this dead code for review I researched and found that it is always advised to remove the dead/unused code(https://www.infoq.com/news/2017/02/dead-code , https://stackoverflow.com/questions/15699995/why-unused-code-should-be-deleted ). Also if we don't remove the dead code and just change second argument passed in setColorValues() for our fix any static analyzer tool will show it as a bug/unreachable code. >From future use case perspective we have version control to get back the logic so it should not be a problem. So I think it's better to clean up the unused code even if we need to do small changes like removing the second argument in other files. Regarding code change mentioned by you in test case: I think you are referring to VolatileImage.validate(GraphicsConfiguration) and checking whether it returns VolatileImage.IMAGE_INCOMPATIBLE. In the test case present in this bug we are creating a Compatible Volatile Image from a GraphicsConfiguration so I think there is no need to validate the compatibility as GC. createCompatibleVolatileImage(int, int ) mentions that it " Returns a VolatileImage with a data layout and color model compatible with this GraphicsConfiguration ". If I am missing something regarding the test case change you have mentioned please guide me. Regards, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Thursday, December 14, 2017 5:19 PM To: Philip Race; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. Hello Jay I looked into the changes. Here are my views. > X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. > The main problem is we do this operation of conversion twice . Your observation is correct. This is a good find. . The double conversion occurs because of mis-match between two objects - . XRCompositeManager that passes pre-multiplied alpha color to prepare XRSolidSrcPict and . XRSolidSrcPict that expects a "non pre-multiplied" alpha color in its prepareSrcPict method. > Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. > So I have completely removed this logic itself as it not needed anywhere else. . In the proposed fix, you have removed a convenience logic in XRColor.java and modified one (XRColor) method signature as well. . In my view, this change is not required at all. Reasons are- . Though the convenience logic isn't used presently, it could definitely come handy in future whenever a need arises. . The change to method's signature has resulted in recursive changes in many other files as well. . The bug and the fix are not related to XRColor object in general. Combining the above observation, the fix would be to correct 2nd argument of below mentioned line from "false" to "true". Thus retain the convenience logic in XRColor.java as well. File: XRSolidSrcPict.java line 50 xrCol.setColorValues(pixelVal, false); // Change false to true Btw, the test case involves drawing on a VolatileImage & getting its snapshot. But it doesn't check if the created volatile image is valid for a particular Graphics configuration before invoking any drawing operation. You could refer to one of the existing test cases and correct the test file. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Phil Race Sent: Tuesday, December 12, 2017 12:15 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8176795: Wrong color drawn when painting translucent colors on volatile images using XRender. The explanation sounds reasonable, although I'd like to give Clemens a chance to review this. -phil. On 12/07/2017 07:16 AM, Jayathirth D V wrote: Hello All, ? Please review the following fix in JDK10 : ? Bug : https://bugs.openjdk.java.net/browse/JDK-8176795 Webrev : http://cr.openjdk.java.net/~jdv/8176795/webrev.00/ ? Issue : When we draw translucent color over an opaque color in Unix from JDK 8 we get different color after composition compared to any other platform. ? Root cause : From JDK 8, X Rendering extension is enabled in Unix and we see this problem only when we use XRender in Unix if we use GLX or ?X11 we don't see any issue. ?Also X Rendering extension expects pre-multiplied alpha color values, so we need to convert the non-premultiplied alpha color values to pre-multiplied alpha color values before give pixel value to XRender for drawing. The main problem is we do this operation of conversion twice: 1) When we call Graphics2D.setColor() it uses ArgbPre PixelConverter based on SurfaceData(here it is XRenderPixMap ArgbPre surface) and converts the color to pre-multiplied values. 2) When we call Graphics2D.fillRect() internally before we compose the destination(opaque color) and source(translucent color) we prepare source render rectangle for X Render extension. Here again we convert the already converted color values to premultiplied values. ? Solution : There is no need for us to do non-pre to pre color conversion again at XRender level so it should be removed. Also this logic of non-pre to pre color conversion at XRender was only used when source is Solid color and not Texture/Gradient. So I have completely removed this logic itself as it not needed anywhere else. ? Thanks, Jay ? From dalibor.topic at oracle.com Thu Dec 14 13:41:01 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 14 Dec 2017 14:41:01 +0100 Subject: [OpenJDK 2D-Dev] Problems logging in to http://bugs.openjdk.java.net In-Reply-To: References: Message-ID: <370b2775-23d1-df7f-55e6-32f8a691f03c@oracle.com> On 14.12.2017 09:21, Dmitry Batrak wrote: > Hello, > > I'm sorry to bother you with this, but I regularly have problems logging > in to OpenJDK issue tracker (bugs.openjdk.java.net > ). I reported this to > help at openjdk.java.net ('Contact Us' link > on log-in page) more than 3 months ago but got no response. I also > couldn't find a suitable mailing list for this question at > http://mail.openjdk.java.net/mailman/listinfo. Maybe someone on this > list can suggest who can I address this to. Try ops @ openjdk. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From matthias.baesken at sap.com Thu Dec 14 15:10:56 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Dec 2017 15:10:56 +0000 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile Message-ID: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on AIX. I created the following bug : https://bugs.openjdk.java.net/browse/JDK-8193515 The compile error we get on AIX (using XLC 12.1) is : === Output from failing command(s) repeated here === * For target support_native_java.desktop_libfontmanager_hb-ot-shape-complex-arabic.o: " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 80.3: 1540-0218 (S) The call does not match any parameter list for "hb_stable_sort". " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable candidate. " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 80.43: 1540-0298 (I) Template argument deduction cannot be performed using the function "template int cmp(Type2) const". " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *))" is not a viable candidate. " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 80.3: 1540-0215 (I) The wrong number of arguments has been specified for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *))". " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 129.3: 1540-0218 (S) The call does not match any parameter list for "hb_stable_sort". " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable candidate. " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 129.55: 1540-0298 (I) Template argument deduction cannot be performed using the function "template int cmp(Type2) const". " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *))" is not a viable candidate. " /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", line 129.3: 1540-0215 (I) The wrong number of arguments has been specified for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, const T *))". The compilation "complains" about the hb_stable_sort template used in hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , the third parameter OT::GlyphID::cmp of hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, &substitutes[0]); seems to trigger this XLC 12 issue . XLC 12 does not like the fact that we have two cmp functions (one a template) in hb-open-type-private.hh : 610 template 611 struct IntType 612 { .... 617 static inline int cmp (const IntType *a, const IntType *b) { return b->cmp (*a); } 622 623 template 624 inline int cmp (Type2 a) const 625 { ( GlyphID is an IntType ) This looks like an XLC bug, however it is pretty easy to workaround it by using a helper compare-function with a unique name (issue with cmp is that it is not unique, that confuses XLC ). See this webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ Please review it. Thanks, Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 14 15:26:47 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 14 Dec 2017 07:26:47 -0800 Subject: [OpenJDK 2D-Dev] Problems logging in to http://bugs.openjdk.java.net In-Reply-To: References: Message-ID: <5A329837.5070704@oracle.com> Perhaps ops at openjdk.java.net for things like this but I'll forward this onto some folks who may be able to help. -phil. On 12/14/17, 12:21 AM, Dmitry Batrak wrote: > Hello, > > I'm sorry to bother you with this, but I regularly have problems > logging in to OpenJDK issue tracker (bugs.openjdk.java.net > ). I reported this to > help at openjdk.java.net ('Contact Us' > link on log-in page) more than 3 months ago but got no response. I > also couldn't find a suitable mailing list for this question at > http://mail.openjdk.java.net/mailman/listinfo. Maybe someone on this > list can suggest who can I address this to. > > For completeness, below is the description of the problem: > > I use 'Log In' link in the top right corner of the website. In the > opened OpenJDK Log In page I enter my email > (Dmitry.Batrak at jetbrains.com ) and > password. After pressing 'Log In' button I'm redirected to the > original bugs.openjdk.java.net page, > but I'm still not logged in (Log In link is still displayed in the top > right corner). I'm sure I'm entering my password correctly, because if > I try a definitely wrong password I get a specific notification about it. > Sometimes it works, but it can take tens of attempts to make it work. > > -- > Best regards, > Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Dec 14 16:13:46 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 14 Dec 2017 17:13:46 +0100 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> Message-ID: Hi Matthias, thanks for addressing this issue! I'm pretty sure that his is a compiler bug and I have a short reproducer which I'll send to IBM. The problem is that xlC can't distinguish a static member function (which uses an ordinary function call) from a non-static member function (which uses a member function call) with the same name. I've just found a slightly more elegant (and less intrusive) fix. We can help the compiler to find the correct method by simply casting it to the correct version: diff -r be065f758154 src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh Thu Dec 14 12:49:47 2017 +0530 +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh Thu Dec 14 17:11:49 2017 +0100 @@ -77,7 +77,7 @@ /* Bubble-sort or something equally good! * May not be good-enough for presidential candidate interviews, but good-enough for us... */ - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, &substitutes[0]); + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); OT::Supplier glyphs_supplier (glyphs, num_glyphs); OT::Supplier substitutes_supplier (substitutes, num_glyphs); @@ -126,7 +126,7 @@ first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; num_first_glyphs++; } - hb_stable_sort (&first_glyphs[0], num_first_glyphs, OT::GlyphID::cmp, &first_glyphs_indirection[0]); + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, &first_glyphs_indirection[0]); /* Now that the first-glyphs are sorted, walk again, populate ligatures. */ for (unsigned int i = 0; i < num_first_glyphs; i++) I'll also try to bring this change upstream into Harfbuzz, but we need to push this into the new jdk/jdk10 repo because there will be no more HarfBuzz integration for Java 10. Regards, Volker On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias wrote: > Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on > AIX. > > > > I created the following bug : > > https://bugs.openjdk.java.net/browse/JDK-8193515 > > > > The compile error we get on AIX (using XLC 12.1) is : > > > > === Output from failing command(s) repeated here === > > * For target > support_native_java.desktop_libfontmanager_hb-ot-shape-complex-arabic.o: > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 80.3: 1540-0218 (S) The call does not match any parameter list for > "hb_stable_sort". > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", > line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > candidate. > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 80.43: 1540-0298 (I) Template argument deduction cannot be performed > using the function "template int cmp(Type2) const". > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", > line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned > int, int (*)(const T *, const T *))" is not a viable candidate. > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 80.3: 1540-0215 (I) The wrong number of arguments has been specified > for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, > const T *))". > > > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 129.3: 1540-0218 (S) The call does not match any parameter list for > "hb_stable_sort". > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", > line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > candidate. > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 129.55: 1540-0298 (I) Template argument deduction cannot be performed > using the function "template int cmp(Type2) const". > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", > line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned > int, int (*)(const T *, const T *))" is not a viable candidate. > > " > /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", > line 129.3: 1540-0215 (I) The wrong number of arguments has been specified > for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, > const T *))". > > > > The compilation ?complains? about the hb_stable_sort template used in > hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , > the third parameter > > OT::GlyphID::cmp > > of > > hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > &substitutes[0]); > > > > seems to trigger this XLC 12 issue . > > XLC 12 does not like the fact that we have two cmp functions (one a > template) in > > > > hb-open-type-private.hh : > > > > 610 template > > 611 struct IntType > > 612 { > > .... > > 617 static inline int cmp (const IntType *a, const > IntType *b) { return b->cmp (*a); } > > 622 > > 623 template > > 624 inline int cmp (Type2 a) const > > 625 { > > > > ( GlyphID is an IntType ) > > This looks like an XLC bug, however it is pretty easy to workaround it by > using a helper compare-function with a unique name (issue with cmp is that > it is not unique, that confuses XLC ). > > See this webrev : > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ > > > > Please review it. > > > > > > Thanks, Matthias From dmitry.batrak at jetbrains.com Thu Dec 14 16:44:24 2017 From: dmitry.batrak at jetbrains.com (Dmitry Batrak) Date: Thu, 14 Dec 2017 19:44:24 +0300 Subject: [OpenJDK 2D-Dev] Problems logging in to http://bugs.openjdk.java.net In-Reply-To: <5A329837.5070704@oracle.com> References: <5A329837.5070704@oracle.com> Message-ID: Thanks! I received a response from ops at openjdk.java.net. On Thu, Dec 14, 2017 at 6:26 PM, Philip Race wrote: > Perhaps ops at openjdk.java.net for things like this but I'll forward this > onto some folks who may be able to help. > > -phil. > > On 12/14/17, 12:21 AM, Dmitry Batrak wrote: > > Hello, > > I'm sorry to bother you with this, but I regularly have problems logging > in to OpenJDK issue tracker (bugs.openjdk.java.net). I reported this to > help at openjdk.java.net ('Contact Us' link on log-in page) more than 3 > months ago but got no response. I also couldn't find a suitable mailing > list for this question at http://mail.openjdk.java.net/mailman/listinfo. > Maybe someone on this list can suggest who can I address this to. > > For completeness, below is the description of the problem: > > I use 'Log In' link in the top right corner of the website. In the opened > OpenJDK Log In page I enter my email (Dmitry.Batrak at jetbrains.com) and > password. After pressing 'Log In' button I'm redirected to the original > bugs.openjdk.java.net page, but I'm still not logged in (Log In link is > still displayed in the top right corner). I'm sure I'm entering my password > correctly, because if I try a definitely wrong password I get a specific > notification about it. > Sometimes it works, but it can take tens of attempts to make it work. > > -- > Best regards, > Dmitry Batrak > > -- Best regards, Dmitry Batrak -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 14 16:53:07 2017 From: philip.race at oracle.com (Phil Race) Date: Thu, 14 Dec 2017 08:53:07 -0800 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> Message-ID: <65c25792-6336-59b6-b620-855bb298e814@oracle.com> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that other platforms are guaranteed to be unaffected ? For upstream you can report it at github https://github.com/harfbuzz/harfbuzz and see how Behdad would like to handle it. I expect he would want it removed once the compiler bug is fixed. -pgil. On 12/14/2017 08:13 AM, Volker Simonis wrote: > Hi Matthias, > > thanks for addressing this issue! > > I'm pretty sure that his is a compiler bug and I have a short > reproducer which I'll send to IBM. > > The problem is that xlC can't distinguish a static member function > (which uses an ordinary function call) from a non-static member > function (which uses a member function call) with the same name. > > I've just found a slightly more elegant (and less intrusive) fix. We > can help the compiler to find the correct method by simply casting it > to the correct version: > > diff -r be065f758154 > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh > Thu Dec 14 12:49:47 2017 +0530 > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh > Thu Dec 14 17:11:49 2017 +0100 > @@ -77,7 +77,7 @@ > > /* Bubble-sort or something equally good! > * May not be good-enough for presidential candidate interviews, > but good-enough for us... */ > - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, &substitutes[0]); > + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID > *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); > > OT::Supplier glyphs_supplier (glyphs, num_glyphs); > OT::Supplier substitutes_supplier (substitutes, num_glyphs); > @@ -126,7 +126,7 @@ > first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; > num_first_glyphs++; > } > - hb_stable_sort (&first_glyphs[0], num_first_glyphs, > OT::GlyphID::cmp, &first_glyphs_indirection[0]); > + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const > OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, > &first_glyphs_indirection[0]); > > /* Now that the first-glyphs are sorted, walk again, populate ligatures. */ > for (unsigned int i = 0; i < num_first_glyphs; i++) > > I'll also try to bring this change upstream into Harfbuzz, but we need > to push this into the new jdk/jdk10 repo because there will be no more > HarfBuzz integration for Java 10. > > Regards, > Volker > > > On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias > wrote: >> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on >> AIX. >> >> >> >> I created the following bug : >> >> https://bugs.openjdk.java.net/browse/JDK-8193515 >> >> >> >> The compile error we get on AIX (using XLC 12.1) is : >> >> >> >> === Output from failing command(s) repeated here === >> >> * For target >> support_native_java.desktop_libfontmanager_hb-ot-shape-complex-arabic.o: >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 80.3: 1540-0218 (S) The call does not match any parameter list for >> "hb_stable_sort". >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >> candidate. >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 80.43: 1540-0298 (I) Template argument deduction cannot be performed >> using the function "template int cmp(Type2) const". >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned >> int, int (*)(const T *, const T *))" is not a viable candidate. >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 80.3: 1540-0215 (I) The wrong number of arguments has been specified >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, >> const T *))". >> >> >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 129.3: 1540-0218 (S) The call does not match any parameter list for >> "hb_stable_sort". >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >> candidate. >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 129.55: 1540-0298 (I) Template argument deduction cannot be performed >> using the function "template int cmp(Type2) const". >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-private.hh", >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned >> int, int (*)(const T *, const T *))" is not a viable candidate. >> >> " >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape-complex-arabic-fallback.hh", >> line 129.3: 1540-0215 (I) The wrong number of arguments has been specified >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, >> const T *))". >> >> >> >> The compilation ?complains? about the hb_stable_sort template used in >> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , >> the third parameter >> >> OT::GlyphID::cmp >> >> of >> >> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >> &substitutes[0]); >> >> >> >> seems to trigger this XLC 12 issue . >> >> XLC 12 does not like the fact that we have two cmp functions (one a >> template) in >> >> >> >> hb-open-type-private.hh : >> >> >> >> 610 template >> >> 611 struct IntType >> >> 612 { >> >> .... >> >> 617 static inline int cmp (const IntType *a, const >> IntType *b) { return b->cmp (*a); } >> >> 622 >> >> 623 template >> >> 624 inline int cmp (Type2 a) const >> >> 625 { >> >> >> >> ( GlyphID is an IntType ) >> >> This looks like an XLC bug, however it is pretty easy to workaround it by >> using a helper compare-function with a unique name (issue with cmp is that >> it is not unique, that confuses XLC ). >> >> See this webrev : >> >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ >> >> >> >> Please review it. >> >> >> >> >> >> Thanks, Matthias From matthias.baesken at sap.com Thu Dec 14 17:02:44 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 14 Dec 2017 17:02:44 +0000 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: <65c25792-6336-59b6-b620-855bb298e814@oracle.com> References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> Message-ID: Hi Phil, hi Volki, I think wrapping Volkis version into #ifdef _AIX plus adding a small comment sounds like a good idea . In the meantime we try to find out how latest xlC version 13 behaves . Best regards, Matthias > -----Original Message----- > From: Phil Race [mailto:philip.race at oracle.com] > Sent: Donnerstag, 14. Dezember 2017 17:53 > To: Volker Simonis ; Baesken, Matthias > > Cc: Simonis, Volker ; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > version fails to compile > > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that > other platforms are guaranteed to be unaffected ? > > For upstream you can report it at github > https://github.com/harfbuzz/harfbuzz > and see how Behdad would like to handle it. > > I expect he would want it removed once the compiler bug is fixed. > > -pgil. > > On 12/14/2017 08:13 AM, Volker Simonis wrote: > > Hi Matthias, > > > > thanks for addressing this issue! > > > > I'm pretty sure that his is a compiler bug and I have a short > > reproducer which I'll send to IBM. > > > > The problem is that xlC can't distinguish a static member function > > (which uses an ordinary function call) from a non-static member > > function (which uses a member function call) with the same name. > > > > I've just found a slightly more elegant (and less intrusive) fix. We > > can help the compiler to find the correct method by simply casting it > > to the correct version: > > > > diff -r be065f758154 > > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- > complex-arabic-fallback.hh > > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh > > Thu Dec 14 12:49:47 2017 +0530 > > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh > > Thu Dec 14 17:11:49 2017 +0100 > > @@ -77,7 +77,7 @@ > > > > /* Bubble-sort or something equally good! > > * May not be good-enough for presidential candidate interviews, > > but good-enough for us... */ > > - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > &substitutes[0]); > > + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID > > *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); > > > > OT::Supplier glyphs_supplier (glyphs, num_glyphs); > > OT::Supplier substitutes_supplier (substitutes, > num_glyphs); > > @@ -126,7 +126,7 @@ > > first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; > > num_first_glyphs++; > > } > > - hb_stable_sort (&first_glyphs[0], num_first_glyphs, > > OT::GlyphID::cmp, &first_glyphs_indirection[0]); > > + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const > > OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, > > &first_glyphs_indirection[0]); > > > > /* Now that the first-glyphs are sorted, walk again, populate ligatures. */ > > for (unsigned int i = 0; i < num_first_glyphs; i++) > > > > I'll also try to bring this change upstream into Harfbuzz, but we need > > to push this into the new jdk/jdk10 repo because there will be no more > > HarfBuzz integration for Java 10. > > > > Regards, > > Volker > > > > > > On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias > > wrote: > >> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on > >> AIX. > >> > >> > >> > >> I created the following bug : > >> > >> https://bugs.openjdk.java.net/browse/JDK-8193515 > >> > >> > >> > >> The compile error we get on AIX (using XLC 12.1) is : > >> > >> > >> > >> === Output from failing command(s) repeated here === > >> > >> * For target > >> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- > arabic.o: > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 80.3: 1540-0218 (S) The call does not match any parameter list for > >> "hb_stable_sort". > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > private.hh", > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > >> candidate. > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 80.43: 1540-0298 (I) Template argument deduction cannot be > performed > >> using the function "template int cmp(Type2) const". > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > private.hh", > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned > >> int, int (*)(const T *, const T *))" is not a viable candidate. > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 80.3: 1540-0215 (I) The wrong number of arguments has been > specified > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, > >> const T *))". > >> > >> > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 129.3: 1540-0218 (S) The call does not match any parameter list for > >> "hb_stable_sort". > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > private.hh", > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > >> candidate. > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 129.55: 1540-0298 (I) Template argument deduction cannot be > performed > >> using the function "template int cmp(Type2) const". > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > private.hh", > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, unsigned > >> int, int (*)(const T *, const T *))" is not a viable candidate. > >> > >> " > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape-complex-arabic-fallback.hh", > >> line 129.3: 1540-0215 (I) The wrong number of arguments has been > specified > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T *, > >> const T *))". > >> > >> > >> > >> The compilation ?complains? about the hb_stable_sort template used in > >> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , > >> the third parameter > >> > >> OT::GlyphID::cmp > >> > >> of > >> > >> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > >> &substitutes[0]); > >> > >> > >> > >> seems to trigger this XLC 12 issue . > >> > >> XLC 12 does not like the fact that we have two cmp functions (one a > >> template) in > >> > >> > >> > >> hb-open-type-private.hh : > >> > >> > >> > >> 610 template > >> > >> 611 struct IntType > >> > >> 612 { > >> > >> .... > >> > >> 617 static inline int cmp (const IntType *a, const > >> IntType *b) { return b->cmp (*a); } > >> > >> 622 > >> > >> 623 template > >> > >> 624 inline int cmp (Type2 a) const > >> > >> 625 { > >> > >> > >> > >> ( GlyphID is an IntType ) > >> > >> This looks like an XLC bug, however it is pretty easy to workaround it by > >> using a helper compare-function with a unique name (issue with cmp is > that > >> it is not unique, that confuses XLC ). > >> > >> See this webrev : > >> > >> > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ > >> > >> > >> > >> Please review it. > >> > >> > >> > >> > >> > >> Thanks, Matthias From matthias.baesken at sap.com Fri Dec 15 13:24:21 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 15 Dec 2017 13:24:21 +0000 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> Message-ID: <17ba51f208c445b9b81880a0051f76e6@sap.com> Hello, I created a second webrev : http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ > > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that > > other platforms are guaranteed to be unaffected ? The new webrev uses the simpler cast-version proposed by Volki , and guards the AIX change by ifdef (suggested by Phil). >> > In the meantime we try to find out how latest xlC version 13 behaves . In the meantime I checked with XLC13 as well , but we see the error with XLC 13 too (same as XLC 12). Please review the change . It should go later into jdk10 as well (because jdk10 contains the new Harfbuzz 1.7.1 too ). Thanks, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Donnerstag, 14. Dezember 2017 18:03 > To: 'Phil Race' ; Volker Simonis > > Cc: Simonis, Volker ; 2d-dev at openjdk.java.net > Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > version fails to compile > > Hi Phil, hi Volki, > I think wrapping Volkis version into #ifdef _AIX > plus adding a small comment sounds like a good idea . > > In the meantime we try to find out how latest xlC version 13 behaves . > > Best regards, Matthias > > > > -----Original Message----- > > From: Phil Race [mailto:philip.race at oracle.com] > > Sent: Donnerstag, 14. Dezember 2017 17:53 > > To: Volker Simonis ; Baesken, Matthias > > > > Cc: Simonis, Volker ; 2d-dev at openjdk.java.net > > Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > > version fails to compile > > > > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that > > other platforms are guaranteed to be unaffected ? > > > > For upstream you can report it at github > > https://github.com/harfbuzz/harfbuzz > > and see how Behdad would like to handle it. > > > > I expect he would want it removed once the compiler bug is fixed. > > > > -pgil. > > > > On 12/14/2017 08:13 AM, Volker Simonis wrote: > > > Hi Matthias, > > > > > > thanks for addressing this issue! > > > > > > I'm pretty sure that his is a compiler bug and I have a short > > > reproducer which I'll send to IBM. > > > > > > The problem is that xlC can't distinguish a static member function > > > (which uses an ordinary function call) from a non-static member > > > function (which uses a member function call) with the same name. > > > > > > I've just found a slightly more elegant (and less intrusive) fix. We > > > can help the compiler to find the correct method by simply casting it > > > to the correct version: > > > > > > diff -r be065f758154 > > > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- > > complex-arabic-fallback.hh > > > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh > > > Thu Dec 14 12:49:47 2017 +0530 > > > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh > > > Thu Dec 14 17:11:49 2017 +0100 > > > @@ -77,7 +77,7 @@ > > > > > > /* Bubble-sort or something equally good! > > > * May not be good-enough for presidential candidate interviews, > > > but good-enough for us... */ > > > - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > > &substitutes[0]); > > > + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID > > > *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); > > > > > > OT::Supplier glyphs_supplier (glyphs, num_glyphs); > > > OT::Supplier substitutes_supplier (substitutes, > > num_glyphs); > > > @@ -126,7 +126,7 @@ > > > first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; > > > num_first_glyphs++; > > > } > > > - hb_stable_sort (&first_glyphs[0], num_first_glyphs, > > > OT::GlyphID::cmp, &first_glyphs_indirection[0]); > > > + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const > > > OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, > > > &first_glyphs_indirection[0]); > > > > > > /* Now that the first-glyphs are sorted, walk again, populate ligatures. > */ > > > for (unsigned int i = 0; i < num_first_glyphs; i++) > > > > > > I'll also try to bring this change upstream into Harfbuzz, but we need > > > to push this into the new jdk/jdk10 repo because there will be no more > > > HarfBuzz integration for Java 10. > > > > > > Regards, > > > Volker > > > > > > > > > On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias > > > wrote: > > >> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on > > >> AIX. > > >> > > >> > > >> > > >> I created the following bug : > > >> > > >> https://bugs.openjdk.java.net/browse/JDK-8193515 > > >> > > >> > > >> > > >> The compile error we get on AIX (using XLC 12.1) is : > > >> > > >> > > >> > > >> === Output from failing command(s) repeated here === > > >> > > >> * For target > > >> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- > > arabic.o: > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 80.3: 1540-0218 (S) The call does not match any parameter list for > > >> "hb_stable_sort". > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > > private.hh", > > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > > >> candidate. > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 80.43: 1540-0298 (I) Template argument deduction cannot be > > performed > > >> using the function "template int cmp(Type2) const". > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > > private.hh", > > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, > unsigned > > >> int, int (*)(const T *, const T *))" is not a viable candidate. > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 80.3: 1540-0215 (I) The wrong number of arguments has been > > specified > > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T > *, > > >> const T *))". > > >> > > >> > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 129.3: 1540-0218 (S) The call does not match any parameter list for > > >> "hb_stable_sort". > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > > private.hh", > > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, > > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > > >> candidate. > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 129.55: 1540-0298 (I) Template argument deduction cannot be > > performed > > >> using the function "template int cmp(Type2) const". > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > > private.hh", > > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, > unsigned > > >> int, int (*)(const T *, const T *))" is not a viable candidate. > > >> > > >> " > > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > > shape-complex-arabic-fallback.hh", > > >> line 129.3: 1540-0215 (I) The wrong number of arguments has been > > specified > > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T > *, > > >> const T *))". > > >> > > >> > > >> > > >> The compilation ?complains? about the hb_stable_sort template used > in > > >> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , > > >> the third parameter > > >> > > >> OT::GlyphID::cmp > > >> > > >> of > > >> > > >> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > > >> &substitutes[0]); > > >> > > >> > > >> > > >> seems to trigger this XLC 12 issue . > > >> > > >> XLC 12 does not like the fact that we have two cmp functions (one a > > >> template) in > > >> > > >> > > >> > > >> hb-open-type-private.hh : > > >> > > >> > > >> > > >> 610 template > > >> > > >> 611 struct IntType > > >> > > >> 612 { > > >> > > >> .... > > >> > > >> 617 static inline int cmp (const IntType *a, const > > >> IntType *b) { return b->cmp (*a); } > > >> > > >> 622 > > >> > > >> 623 template > > >> > > >> 624 inline int cmp (Type2 a) const > > >> > > >> 625 { > > >> > > >> > > >> > > >> ( GlyphID is an IntType ) > > >> > > >> This looks like an XLC bug, however it is pretty easy to workaround it by > > >> using a helper compare-function with a unique name (issue with cmp is > > that > > >> it is not unique, that confuses XLC ). > > >> > > >> See this webrev : > > >> > > >> > > >> > > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ > > >> > > >> > > >> > > >> Please review it. > > >> > > >> > > >> > > >> > > >> > > >> Thanks, Matthias From volker.simonis at gmail.com Mon Dec 18 09:51:01 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 18 Dec 2017 10:51:01 +0100 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: <17ba51f208c445b9b81880a0051f76e6@sap.com> References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> <17ba51f208c445b9b81880a0051f76e6@sap.com> Message-ID: Hi Matthias, the change looks good and I can sponsor it. I'd just propose to slightly change the comment to "..by the overloaded versions of 'cmp' in IntType" if you don't mind. There's no need for a new webrew tough - I can make that change before pushing. I'm just waiting for one more review from the 2D group. Afterwards I'll push directly to jdk/jdk10. From my understanding, the fix will than be automatically forward-integrated into jdk/jdk. Regards, Volker On Fri, Dec 15, 2017 at 2:24 PM, Baesken, Matthias wrote: > Hello, I created a second webrev : > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ > > >> > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >> > other platforms are guaranteed to be unaffected ? > > The new webrev uses the simpler cast-version proposed by Volki , and guards the AIX change by ifdef (suggested by Phil). > >>> > In the meantime we try to find out how latest xlC version 13 behaves . > > In the meantime I checked with XLC13 as well , but we see the error with XLC 13 too (same as XLC 12). > > Please review the change . > > It should go later into jdk10 as well (because jdk10 contains the new Harfbuzz 1.7.1 too ). > > > Thanks, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Donnerstag, 14. Dezember 2017 18:03 >> To: 'Phil Race' ; Volker Simonis >> >> Cc: Simonis, Volker ; 2d-dev at openjdk.java.net >> Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >> version fails to compile >> >> Hi Phil, hi Volki, >> I think wrapping Volkis version into #ifdef _AIX >> plus adding a small comment sounds like a good idea . >> >> In the meantime we try to find out how latest xlC version 13 behaves . >> >> Best regards, Matthias >> >> >> > -----Original Message----- >> > From: Phil Race [mailto:philip.race at oracle.com] >> > Sent: Donnerstag, 14. Dezember 2017 17:53 >> > To: Volker Simonis ; Baesken, Matthias >> > >> > Cc: Simonis, Volker ; 2d-dev at openjdk.java.net >> > Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >> > version fails to compile >> > >> > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >> > other platforms are guaranteed to be unaffected ? >> > >> > For upstream you can report it at github >> > https://github.com/harfbuzz/harfbuzz >> > and see how Behdad would like to handle it. >> > >> > I expect he would want it removed once the compiler bug is fixed. >> > >> > -pgil. >> > >> > On 12/14/2017 08:13 AM, Volker Simonis wrote: >> > > Hi Matthias, >> > > >> > > thanks for addressing this issue! >> > > >> > > I'm pretty sure that his is a compiler bug and I have a short >> > > reproducer which I'll send to IBM. >> > > >> > > The problem is that xlC can't distinguish a static member function >> > > (which uses an ordinary function call) from a non-static member >> > > function (which uses a member function call) with the same name. >> > > >> > > I've just found a slightly more elegant (and less intrusive) fix. We >> > > can help the compiler to find the correct method by simply casting it >> > > to the correct version: >> > > >> > > diff -r be065f758154 >> > > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- >> > complex-arabic-fallback.hh >> > > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh >> > > Thu Dec 14 12:49:47 2017 +0530 >> > > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh >> > > Thu Dec 14 17:11:49 2017 +0100 >> > > @@ -77,7 +77,7 @@ >> > > >> > > /* Bubble-sort or something equally good! >> > > * May not be good-enough for presidential candidate interviews, >> > > but good-enough for us... */ >> > > - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >> > &substitutes[0]); >> > > + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID >> > > *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); >> > > >> > > OT::Supplier glyphs_supplier (glyphs, num_glyphs); >> > > OT::Supplier substitutes_supplier (substitutes, >> > num_glyphs); >> > > @@ -126,7 +126,7 @@ >> > > first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; >> > > num_first_glyphs++; >> > > } >> > > - hb_stable_sort (&first_glyphs[0], num_first_glyphs, >> > > OT::GlyphID::cmp, &first_glyphs_indirection[0]); >> > > + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const >> > > OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, >> > > &first_glyphs_indirection[0]); >> > > >> > > /* Now that the first-glyphs are sorted, walk again, populate ligatures. >> */ >> > > for (unsigned int i = 0; i < num_first_glyphs; i++) >> > > >> > > I'll also try to bring this change upstream into Harfbuzz, but we need >> > > to push this into the new jdk/jdk10 repo because there will be no more >> > > HarfBuzz integration for Java 10. >> > > >> > > Regards, >> > > Volker >> > > >> > > >> > > On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias >> > > wrote: >> > >> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on >> > >> AIX. >> > >> >> > >> >> > >> >> > >> I created the following bug : >> > >> >> > >> https://bugs.openjdk.java.net/browse/JDK-8193515 >> > >> >> > >> >> > >> >> > >> The compile error we get on AIX (using XLC 12.1) is : >> > >> >> > >> >> > >> >> > >> === Output from failing command(s) repeated here === >> > >> >> > >> * For target >> > >> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- >> > arabic.o: >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 80.3: 1540-0218 (S) The call does not match any parameter list for >> > >> "hb_stable_sort". >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >> > private.hh", >> > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >> > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >> > >> candidate. >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 80.43: 1540-0298 (I) Template argument deduction cannot be >> > performed >> > >> using the function "template int cmp(Type2) const". >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >> > private.hh", >> > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >> unsigned >> > >> int, int (*)(const T *, const T *))" is not a viable candidate. >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 80.3: 1540-0215 (I) The wrong number of arguments has been >> > specified >> > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T >> *, >> > >> const T *))". >> > >> >> > >> >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 129.3: 1540-0218 (S) The call does not match any parameter list for >> > >> "hb_stable_sort". >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >> > private.hh", >> > >> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >> > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >> > >> candidate. >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 129.55: 1540-0298 (I) Template argument deduction cannot be >> > performed >> > >> using the function "template int cmp(Type2) const". >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >> > private.hh", >> > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >> unsigned >> > >> int, int (*)(const T *, const T *))" is not a viable candidate. >> > >> >> > >> " >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >> > shape-complex-arabic-fallback.hh", >> > >> line 129.3: 1540-0215 (I) The wrong number of arguments has been >> > specified >> > >> for "template hb_stable_sort(T *, unsigned int, int (*)(const T >> *, >> > >> const T *))". >> > >> >> > >> >> > >> >> > >> The compilation ?complains? about the hb_stable_sort template used >> in >> > >> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , >> > >> the third parameter >> > >> >> > >> OT::GlyphID::cmp >> > >> >> > >> of >> > >> >> > >> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >> > >> &substitutes[0]); >> > >> >> > >> >> > >> >> > >> seems to trigger this XLC 12 issue . >> > >> >> > >> XLC 12 does not like the fact that we have two cmp functions (one a >> > >> template) in >> > >> >> > >> >> > >> >> > >> hb-open-type-private.hh : >> > >> >> > >> >> > >> >> > >> 610 template >> > >> >> > >> 611 struct IntType >> > >> >> > >> 612 { >> > >> >> > >> .... >> > >> >> > >> 617 static inline int cmp (const IntType *a, const >> > >> IntType *b) { return b->cmp (*a); } >> > >> >> > >> 622 >> > >> >> > >> 623 template >> > >> >> > >> 624 inline int cmp (Type2 a) const >> > >> >> > >> 625 { >> > >> >> > >> >> > >> >> > >> ( GlyphID is an IntType ) >> > >> >> > >> This looks like an XLC bug, however it is pretty easy to workaround it by >> > >> using a helper compare-function with a unique name (issue with cmp is >> > that >> > >> it is not unique, that confuses XLC ). >> > >> >> > >> See this webrev : >> > >> >> > >> >> > >> >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ >> > >> >> > >> >> > >> >> > >> Please review it. >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> Thanks, Matthias > From matthias.baesken at sap.com Mon Dec 18 11:01:12 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Mon, 18 Dec 2017 11:01:12 +0000 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> <17ba51f208c445b9b81880a0051f76e6@sap.com> Message-ID: <76c4a1d329a341cc81df240815a828aa@sap.com> Thanks! > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Montag, 18. Dezember 2017 10:51 > To: Baesken, Matthias > Cc: Phil Race ; Simonis, Volker > ; 2d-dev at openjdk.java.net > Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > version fails to compile > > Hi Matthias, > > the change looks good and I can sponsor it. I'd just propose to > slightly change the comment to "..by the overloaded versions of 'cmp' > in IntType" if you don't mind. There's no need for a new webrew tough > - I can make that change before pushing. > > I'm just waiting for one more review from the 2D group. Afterwards > I'll push directly to jdk/jdk10. From my understanding, the fix will > than be automatically forward-integrated into jdk/jdk. > > Regards, > Volker > > > On Fri, Dec 15, 2017 at 2:24 PM, Baesken, Matthias > wrote: > > Hello, I created a second webrev : > > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ > > > > > >> > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that > >> > other platforms are guaranteed to be unaffected ? > > > > The new webrev uses the simpler cast-version proposed by Volki , and > guards the AIX change by ifdef (suggested by Phil). > > > >>> > In the meantime we try to find out how latest xlC version 13 behaves . > > > > In the meantime I checked with XLC13 as well , but we see the error with > XLC 13 too (same as XLC 12). > > > > Please review the change . > > > > It should go later into jdk10 as well (because jdk10 contains the new > Harfbuzz 1.7.1 too ). > > > > > > Thanks, Matthias > > > > > >> -----Original Message----- > >> From: Baesken, Matthias > >> Sent: Donnerstag, 14. Dezember 2017 18:03 > >> To: 'Phil Race' ; Volker Simonis > >> > >> Cc: Simonis, Volker ; 2d- > dev at openjdk.java.net > >> Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > >> version fails to compile > >> > >> Hi Phil, hi Volki, > >> I think wrapping Volkis version into #ifdef _AIX > >> plus adding a small comment sounds like a good idea . > >> > >> In the meantime we try to find out how latest xlC version 13 behaves . > >> > >> Best regards, Matthias > >> > >> > >> > -----Original Message----- > >> > From: Phil Race [mailto:philip.race at oracle.com] > >> > Sent: Donnerstag, 14. Dezember 2017 17:53 > >> > To: Volker Simonis ; Baesken, Matthias > >> > > >> > Cc: Simonis, Volker ; 2d- > dev at openjdk.java.net > >> > Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 > >> > version fails to compile > >> > > >> > Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that > >> > other platforms are guaranteed to be unaffected ? > >> > > >> > For upstream you can report it at github > >> > https://github.com/harfbuzz/harfbuzz > >> > and see how Behdad would like to handle it. > >> > > >> > I expect he would want it removed once the compiler bug is fixed. > >> > > >> > -pgil. > >> > > >> > On 12/14/2017 08:13 AM, Volker Simonis wrote: > >> > > Hi Matthias, > >> > > > >> > > thanks for addressing this issue! > >> > > > >> > > I'm pretty sure that his is a compiler bug and I have a short > >> > > reproducer which I'll send to IBM. > >> > > > >> > > The problem is that xlC can't distinguish a static member function > >> > > (which uses an ordinary function call) from a non-static member > >> > > function (which uses a member function call) with the same name. > >> > > > >> > > I've just found a slightly more elegant (and less intrusive) fix. We > >> > > can help the compiler to find the correct method by simply casting it > >> > > to the correct version: > >> > > > >> > > diff -r be065f758154 > >> > > src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > shape- > >> > complex-arabic-fallback.hh > >> > > --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh > >> > > Thu Dec 14 12:49:47 2017 +0530 > >> > > +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > ot- > >> > shape-complex-arabic-fallback.hh > >> > > Thu Dec 14 17:11:49 2017 +0100 > >> > > @@ -77,7 +77,7 @@ > >> > > > >> > > /* Bubble-sort or something equally good! > >> > > * May not be good-enough for presidential candidate interviews, > >> > > but good-enough for us... */ > >> > > - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > >> > &substitutes[0]); > >> > > + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID > >> > > *, const OT::GlyphID *)) OT::GlyphID::cmp, &substitutes[0]); > >> > > > >> > > OT::Supplier glyphs_supplier (glyphs, num_glyphs); > >> > > OT::Supplier substitutes_supplier (substitutes, > >> > num_glyphs); > >> > > @@ -126,7 +126,7 @@ > >> > > first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; > >> > > num_first_glyphs++; > >> > > } > >> > > - hb_stable_sort (&first_glyphs[0], num_first_glyphs, > >> > > OT::GlyphID::cmp, &first_glyphs_indirection[0]); > >> > > + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const > >> > > OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, > >> > > &first_glyphs_indirection[0]); > >> > > > >> > > /* Now that the first-glyphs are sorted, walk again, populate > ligatures. > >> */ > >> > > for (unsigned int i = 0; i < num_first_glyphs; i++) > >> > > > >> > > I'll also try to bring this change upstream into Harfbuzz, but we need > >> > > to push this into the new jdk/jdk10 repo because there will be no > more > >> > > HarfBuzz integration for Java 10. > >> > > > >> > > Regards, > >> > > Volker > >> > > > >> > > > >> > > On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias > >> > > wrote: > >> > >> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails > on > >> > >> AIX. > >> > >> > >> > >> > >> > >> > >> > >> I created the following bug : > >> > >> > >> > >> https://bugs.openjdk.java.net/browse/JDK-8193515 > >> > >> > >> > >> > >> > >> > >> > >> The compile error we get on AIX (using XLC 12.1) is : > >> > >> > >> > >> > >> > >> > >> > >> === Output from failing command(s) repeated here === > >> > >> > >> > >> * For target > >> > >> support_native_java.desktop_libfontmanager_hb-ot-shape- > complex- > >> > arabic.o: > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 80.3: 1540-0218 (S) The call does not match any parameter list for > >> > >> "hb_stable_sort". > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > >> > private.hh", > >> > >> line 723.1: 1540-1283 (I) "template > hb_stable_sort(T *, > >> > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > >> > >> candidate. > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 80.43: 1540-0298 (I) Template argument deduction cannot be > >> > performed > >> > >> using the function "template int cmp(Type2) const". > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > >> > private.hh", > >> > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, > >> unsigned > >> > >> int, int (*)(const T *, const T *))" is not a viable candidate. > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 80.3: 1540-0215 (I) The wrong number of arguments has been > >> > specified > >> > >> for "template hb_stable_sort(T *, unsigned int, int > (*)(const T > >> *, > >> > >> const T *))". > >> > >> > >> > >> > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 129.3: 1540-0218 (S) The call does not match any parameter list > for > >> > >> "hb_stable_sort". > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > >> > private.hh", > >> > >> line 723.1: 1540-1283 (I) "template > hb_stable_sort(T *, > >> > >> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable > >> > >> candidate. > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 129.55: 1540-0298 (I) Template argument deduction cannot be > >> > performed > >> > >> using the function "template int cmp(Type2) const". > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- > >> > private.hh", > >> > >> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, > >> unsigned > >> > >> int, int (*)(const T *, const T *))" is not a viable candidate. > >> > >> > >> > >> " > >> > >> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- > >> > shape-complex-arabic-fallback.hh", > >> > >> line 129.3: 1540-0215 (I) The wrong number of arguments has been > >> > specified > >> > >> for "template hb_stable_sort(T *, unsigned int, int > (*)(const T > >> *, > >> > >> const T *))". > >> > >> > >> > >> > >> > >> > >> > >> The compilation ?complains? about the hb_stable_sort template > used > >> in > >> > >> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this > , > >> > >> the third parameter > >> > >> > >> > >> OT::GlyphID::cmp > >> > >> > >> > >> of > >> > >> > >> > >> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, > >> > >> &substitutes[0]); > >> > >> > >> > >> > >> > >> > >> > >> seems to trigger this XLC 12 issue . > >> > >> > >> > >> XLC 12 does not like the fact that we have two cmp functions (one a > >> > >> template) in > >> > >> > >> > >> > >> > >> > >> > >> hb-open-type-private.hh : > >> > >> > >> > >> > >> > >> > >> > >> 610 template > >> > >> > >> > >> 611 struct IntType > >> > >> > >> > >> 612 { > >> > >> > >> > >> .... > >> > >> > >> > >> 617 static inline int cmp (const IntType *a, const > >> > >> IntType *b) { return b->cmp (*a); } > >> > >> > >> > >> 622 > >> > >> > >> > >> 623 template > >> > >> > >> > >> 624 inline int cmp (Type2 a) const > >> > >> > >> > >> 625 { > >> > >> > >> > >> > >> > >> > >> > >> ( GlyphID is an IntType ) > >> > >> > >> > >> This looks like an XLC bug, however it is pretty easy to workaround it > by > >> > >> using a helper compare-function with a unique name (issue with > cmp is > >> > that > >> > >> it is not unique, that confuses XLC ). > >> > >> > >> > >> See this webrev : > >> > >> > >> > >> > >> > >> > >> > >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ > >> > >> > >> > >> > >> > >> > >> > >> Please review it. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> Thanks, Matthias > > From philip.race at oracle.com Mon Dec 18 17:24:24 2017 From: philip.race at oracle.com (Philip Race) Date: Mon, 18 Dec 2017 09:24:24 -0800 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> <17ba51f208c445b9b81880a0051f76e6@sap.com> Message-ID: <5A37F9C8.8010500@oracle.com> +1 from me .. yes push to jdk/jdk10. -phil. On 12/18/17, 1:51 AM, Volker Simonis wrote: > Hi Matthias, > > the change looks good and I can sponsor it. I'd just propose to > slightly change the comment to "..by the overloaded versions of 'cmp' > in IntType" if you don't mind. There's no need for a new webrew tough > - I can make that change before pushing. > > I'm just waiting for one more review from the 2D group. Afterwards > I'll push directly to jdk/jdk10. From my understanding, the fix will > than be automatically forward-integrated into jdk/jdk. > > Regards, > Volker > > > On Fri, Dec 15, 2017 at 2:24 PM, Baesken, Matthias > wrote: >> Hello, I created a second webrev : >> >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ >> >> >>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>> other platforms are guaranteed to be unaffected ? >> The new webrev uses the simpler cast-version proposed by Volki , and guards the AIX change by ifdef (suggested by Phil). >> >>>>> In the meantime we try to find out how latest xlC version 13 behaves . >> In the meantime I checked with XLC13 as well , but we see the error with XLC 13 too (same as XLC 12). >> >> Please review the change . >> >> It should go later into jdk10 as well (because jdk10 contains the new Harfbuzz 1.7.1 too ). >> >> >> Thanks, Matthias >> >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Donnerstag, 14. Dezember 2017 18:03 >>> To: 'Phil Race'; Volker Simonis >>> >>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>> Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>> version fails to compile >>> >>> Hi Phil, hi Volki, >>> I think wrapping Volkis version into #ifdef _AIX >>> plus adding a small comment sounds like a good idea . >>> >>> In the meantime we try to find out how latest xlC version 13 behaves . >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Phil Race [mailto:philip.race at oracle.com] >>>> Sent: Donnerstag, 14. Dezember 2017 17:53 >>>> To: Volker Simonis; Baesken, Matthias >>>> >>>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>>> version fails to compile >>>> >>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>> other platforms are guaranteed to be unaffected ? >>>> >>>> For upstream you can report it at github >>>> https://github.com/harfbuzz/harfbuzz >>>> and see how Behdad would like to handle it. >>>> >>>> I expect he would want it removed once the compiler bug is fixed. >>>> >>>> -pgil. >>>> >>>> On 12/14/2017 08:13 AM, Volker Simonis wrote: >>>>> Hi Matthias, >>>>> >>>>> thanks for addressing this issue! >>>>> >>>>> I'm pretty sure that his is a compiler bug and I have a short >>>>> reproducer which I'll send to IBM. >>>>> >>>>> The problem is that xlC can't distinguish a static member function >>>>> (which uses an ordinary function call) from a non-static member >>>>> function (which uses a member function call) with the same name. >>>>> >>>>> I've just found a slightly more elegant (and less intrusive) fix. We >>>>> can help the compiler to find the correct method by simply casting it >>>>> to the correct version: >>>>> >>>>> diff -r be065f758154 >>>>> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- >>>> complex-arabic-fallback.hh >>>>> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh >>>>> Thu Dec 14 12:49:47 2017 +0530 >>>>> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh >>>>> Thu Dec 14 17:11:49 2017 +0100 >>>>> @@ -77,7 +77,7 @@ >>>>> >>>>> /* Bubble-sort or something equally good! >>>>> * May not be good-enough for presidential candidate interviews, >>>>> but good-enough for us... */ >>>>> - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>> &substitutes[0]); >>>>> + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID >>>>> *, const OT::GlyphID *)) OT::GlyphID::cmp,&substitutes[0]); >>>>> >>>>> OT::Supplier glyphs_supplier (glyphs, num_glyphs); >>>>> OT::Supplier substitutes_supplier (substitutes, >>>> num_glyphs); >>>>> @@ -126,7 +126,7 @@ >>>>> first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; >>>>> num_first_glyphs++; >>>>> } >>>>> - hb_stable_sort (&first_glyphs[0], num_first_glyphs, >>>>> OT::GlyphID::cmp,&first_glyphs_indirection[0]); >>>>> + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const >>>>> OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, >>>>> &first_glyphs_indirection[0]); >>>>> >>>>> /* Now that the first-glyphs are sorted, walk again, populate ligatures. >>> */ >>>>> for (unsigned int i = 0; i< num_first_glyphs; i++) >>>>> >>>>> I'll also try to bring this change upstream into Harfbuzz, but we need >>>>> to push this into the new jdk/jdk10 repo because there will be no more >>>>> HarfBuzz integration for Java 10. >>>>> >>>>> Regards, >>>>> Volker >>>>> >>>>> >>>>> On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias >>>>> wrote: >>>>>> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build fails on >>>>>> AIX. >>>>>> >>>>>> >>>>>> >>>>>> I created the following bug : >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8193515 >>>>>> >>>>>> >>>>>> >>>>>> The compile error we get on AIX (using XLC 12.1) is : >>>>>> >>>>>> >>>>>> >>>>>> === Output from failing command(s) repeated here === >>>>>> >>>>>> * For target >>>>>> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- >>>> arabic.o: >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 80.3: 1540-0218 (S) The call does not match any parameter list for >>>>>> "hb_stable_sort". >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>> private.hh", >>>>>> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>> candidate. >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 80.43: 1540-0298 (I) Template argument deduction cannot be >>>> performed >>>>>> using the function "template int cmp(Type2) const". >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>> private.hh", >>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>> unsigned >>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 80.3: 1540-0215 (I) The wrong number of arguments has been >>>> specified >>>>>> for "template hb_stable_sort(T *, unsigned int, int (*)(const T >>> *, >>>>>> const T *))". >>>>>> >>>>>> >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 129.3: 1540-0218 (S) The call does not match any parameter list for >>>>>> "hb_stable_sort". >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>> private.hh", >>>>>> line 723.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>> candidate. >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 129.55: 1540-0298 (I) Template argument deduction cannot be >>>> performed >>>>>> using the function "template int cmp(Type2) const". >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>> private.hh", >>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>> unsigned >>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>> >>>>>> " >>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>> shape-complex-arabic-fallback.hh", >>>>>> line 129.3: 1540-0215 (I) The wrong number of arguments has been >>>> specified >>>>>> for "template hb_stable_sort(T *, unsigned int, int (*)(const T >>> *, >>>>>> const T *))". >>>>>> >>>>>> >>>>>> >>>>>> The compilation ?complains? about the hb_stable_sort template used >>> in >>>>>> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into this , >>>>>> the third parameter >>>>>> >>>>>> OT::GlyphID::cmp >>>>>> >>>>>> of >>>>>> >>>>>> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>>>> &substitutes[0]); >>>>>> >>>>>> >>>>>> >>>>>> seems to trigger this XLC 12 issue . >>>>>> >>>>>> XLC 12 does not like the fact that we have two cmp functions (one a >>>>>> template) in >>>>>> >>>>>> >>>>>> >>>>>> hb-open-type-private.hh : >>>>>> >>>>>> >>>>>> >>>>>> 610 template >>>>>> >>>>>> 611 struct IntType >>>>>> >>>>>> 612 { >>>>>> >>>>>> .... >>>>>> >>>>>> 617 static inline int cmp (const IntType *a, const >>>>>> IntType *b) { return b->cmp (*a); } >>>>>> >>>>>> 622 >>>>>> >>>>>> 623 template >>>>>> >>>>>> 624 inline int cmp (Type2 a) const >>>>>> >>>>>> 625 { >>>>>> >>>>>> >>>>>> >>>>>> ( GlyphID is an IntType ) >>>>>> >>>>>> This looks like an XLC bug, however it is pretty easy to workaround it by >>>>>> using a helper compare-function with a unique name (issue with cmp is >>>> that >>>>>> it is not unique, that confuses XLC ). >>>>>> >>>>>> See this webrev : >>>>>> >>>>>> >>>>>> >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ >>>>>> >>>>>> >>>>>> >>>>>> Please review it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Thanks, Matthias From jayathirth.d.v at oracle.com Tue Dec 19 04:55:02 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 18 Dec 2017 20:55:02 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> References: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> Message-ID: Hi Sergey, Could you please provide your inputs and review the fix. Thanks, Jay -----Original Message----- From: Jayathirth D V Sent: Thursday, December 14, 2017 9:47 AM To: Sergey Bylokhov; Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing Hello Sergey, Thanks for your inputs. Comparison using == just comes out of me because of my coding style. Since the variable name PLTE_present is self-explanatory that it is of type boolean I also feel from verbose perspective we should use ! operator. I have updated the code to reflect the same. Apart from verbose perspective is there anything different in Java between using == & ! in this case. Please provide your inputs as it would be helpful in future changes. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8190997/webrev.02/ Thanks, Jay -----Original Message----- From: Sergey Bylokhov Sent: Wednesday, December 13, 2017 9:35 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing It looks fine, but I wonder why metadata.PLTE_present == false is used instead of !metadata.PLTE_present On 13/12/2017 02:50, Jayathirth D V wrote: > Hello Prahalad, > > Thanks for your inputs. > I have updated the code based on your inputs. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Wednesday, December 13, 2017 3:29 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello Jay > > I looked into the changes. > The logic to check the presence of PLTE chunk is correct. > > Few minor changes > . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. > . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. > . You can move the if condition within the if block that stores location of 1st IDAT chunk. > > . Secondly, the wording within the IIOException can be changed. > . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. > . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" > > Thank you > Have a good day > > Prahalad N. > > ----- Original Message ----- > From: Jayathirth D V > Sent: Wednesday, December 13, 2017 3:02 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello All, > > Please review the following fix in JDK10 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 > Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ > > Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. > > Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. > > Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. > > Thanks, > Jay > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Dec 19 07:03:46 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 18 Dec 2017 23:03:46 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> Message-ID: <96d526c3-7172-838a-6a10-d8956151bfbe@oracle.com> The .02 version looks fine. On 18/12/2017 20:55, Jayathirth D V wrote: > Hi Sergey, > > Could you please provide your inputs and review the fix. > > Thanks, > Jay > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, December 14, 2017 9:47 AM > To: Sergey Bylokhov; Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > Hello Sergey, > > Thanks for your inputs. > Comparison using == just comes out of me because of my coding style. > Since the variable name PLTE_present is self-explanatory that it is of type boolean I also feel from verbose perspective we should use ! operator. > I have updated the code to reflect the same. > > Apart from verbose perspective is there anything different in Java between using == & ! in this case. Please provide your inputs as it would be helpful in future changes. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/8190997/webrev.02/ > > Thanks, > Jay > > -----Original Message----- > From: Sergey Bylokhov > Sent: Wednesday, December 13, 2017 9:35 PM > To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing > > It looks fine, but I wonder why > metadata.PLTE_present == false > is used instead of > !metadata.PLTE_present > > On 13/12/2017 02:50, Jayathirth D V wrote: >> Hello Prahalad, >> >> Thanks for your inputs. >> I have updated the code based on your inputs. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/8190997/webrev.01/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Wednesday, December 13, 2017 3:29 PM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing >> >> Hello Jay >> >> I looked into the changes. >> The logic to check the presence of PLTE chunk is correct. >> >> Few minor changes >> . The if condition to check whether PLTE chunk exists would get executed every time an IDAT chunk is encountered. >> . For png images with multiple IDAT chunks, this is a repeated check and can be avoided. >> . You can move the if condition within the if block that stores location of 1st IDAT chunk. >> >> . Secondly, the wording within the IIOException can be changed. >> . PNG specification mentions IHDR chunk as Image Header and this is separate from PLTE chunk. >> . So you could rephrase "PNG Header doesn't contain required PLTE chunk" as "PNG image doesn't contain required PLTE chunk" >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> ----- Original Message ----- >> From: Jayathirth D V >> Sent: Wednesday, December 13, 2017 3:02 PM >> To: 2d-dev >> Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing >> >> Hello All, >> >> Please review the following fix in JDK10 : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-8190997 >> Webrev : http://cr.openjdk.java.net/~jdv/8190997/webrev.00/ >> >> Issue : When we try to read PNG image with color type as PNG_COLOR_PALETTE in IHDR header but missing the required PLTE chunk we throw NullPointerException. >> >> Root cause : We finish reading metadata but when we try to read image information and access palette related data it throws NPE as palette related data is not initialized/not present. >> >> Solution : PNG specification mandates that if color type present in IHDR is PNG_COLOR_PALETTE(type 3), PLTE chunk should appear before the first IDAT chunk. So while reading metadata itself we should verify the same and if required PLTE chunk is absent we should throw proper IIOException instead of allowing the code to continue further and throw NPE while trying to access palette information. >> >> Thanks, >> Jay >> > > -- Best regards, Sergey. From prahalad.kumar.narayanan at oracle.com Tue Dec 19 09:38:25 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 19 Dec 2017 01:38:25 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> Message-ID: <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> Hello Jay Good day to you. I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. Here is a simple math that considers the worst case scenario with max values: . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- max_width : (2 ^ 31) - 1 = 2147483647 max_input_bands = 4 max_bit_depth = 16 (2 Bytes) . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. // Fits into "long" data type max_bits_per_row = max_width * max_input_bands * max_bit_depth = 2147483647 x 4 x 16 = 137438953408 // Does not fit into "int" data type max_bytes_per_row = max_bits_per_row + 7 / 8 = 17179869176 = (0x 3FFFFFFF8 - Goes beyond 4B boundary) // Upon division by 2 for 16-bit images max_elts_per_row = max_bytes_per_row / 2 = 8589934588 = (0x 1FFFFFFFC - Goes beyond 4B boundary) . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Thursday, December 14, 2017 1:48 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello All, Please review the following fix in JDK : Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". Exception in thread "main" java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride ??????????????? at java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelInterleavedSampleModel.java:101) ??????????????? at java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java:642) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(PNGImageReader.java:974) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1099) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1295) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1420) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1699) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) ??????????????? at PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java:50) Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. Thanks, Jay From volker.simonis at gmail.com Tue Dec 19 10:43:33 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 19 Dec 2017 11:43:33 +0100 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: <5A37F9C8.8010500@oracle.com> References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> <17ba51f208c445b9b81880a0051f76e6@sap.com> <5A37F9C8.8010500@oracle.com> Message-ID: Thanks Phil! I've just pushed this to jdk/jdk10. I've also opened an issue [1] in the upstream Harfbuzz project and submitted a pull request with the fix [2]. So hopefully this won't be an issue with the next integration any more. Regards, Volker [1] https://github.com/harfbuzz/harfbuzz/issues/655 [2] https://github.com/harfbuzz/harfbuzz/pull/656 On Mon, Dec 18, 2017 at 6:24 PM, Philip Race wrote: > +1 from me .. > > yes push to jdk/jdk10. > > -phil. > > > On 12/18/17, 1:51 AM, Volker Simonis wrote: >> >> Hi Matthias, >> >> the change looks good and I can sponsor it. I'd just propose to >> slightly change the comment to "..by the overloaded versions of 'cmp' >> in IntType" if you don't mind. There's no need for a new webrew tough >> - I can make that change before pushing. >> >> I'm just waiting for one more review from the 2D group. Afterwards >> I'll push directly to jdk/jdk10. From my understanding, the fix will >> than be automatically forward-integrated into jdk/jdk. >> >> Regards, >> Volker >> >> >> On Fri, Dec 15, 2017 at 2:24 PM, Baesken, Matthias >> wrote: >>> >>> Hello, I created a second webrev : >>> >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ >>> >>> >>>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>>> other platforms are guaranteed to be unaffected ? >>> >>> The new webrev uses the simpler cast-version proposed by Volki , and >>> guards the AIX change by ifdef (suggested by Phil). >>> >>>>>> In the meantime we try to find out how latest xlC version 13 behaves . >>> >>> In the meantime I checked with XLC13 as well , but we see the error >>> with XLC 13 too (same as XLC 12). >>> >>> Please review the change . >>> >>> It should go later into jdk10 as well (because jdk10 contains the new >>> Harfbuzz 1.7.1 too ). >>> >>> >>> Thanks, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Baesken, Matthias >>>> Sent: Donnerstag, 14. Dezember 2017 18:03 >>>> To: 'Phil Race'; Volker Simonis >>>> >>>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>>> Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>>> version fails to compile >>>> >>>> Hi Phil, hi Volki, >>>> I think wrapping Volkis version into #ifdef _AIX >>>> plus adding a small comment sounds like a good idea . >>>> >>>> In the meantime we try to find out how latest xlC version 13 behaves . >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>> Sent: Donnerstag, 14. Dezember 2017 17:53 >>>>> To: Volker Simonis; Baesken, Matthias >>>>> >>>>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>>>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>>>> version fails to compile >>>>> >>>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>>> other platforms are guaranteed to be unaffected ? >>>>> >>>>> For upstream you can report it at github >>>>> https://github.com/harfbuzz/harfbuzz >>>>> and see how Behdad would like to handle it. >>>>> >>>>> I expect he would want it removed once the compiler bug is fixed. >>>>> >>>>> -pgil. >>>>> >>>>> On 12/14/2017 08:13 AM, Volker Simonis wrote: >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> thanks for addressing this issue! >>>>>> >>>>>> I'm pretty sure that his is a compiler bug and I have a short >>>>>> reproducer which I'll send to IBM. >>>>>> >>>>>> The problem is that xlC can't distinguish a static member function >>>>>> (which uses an ordinary function call) from a non-static member >>>>>> function (which uses a member function call) with the same name. >>>>>> >>>>>> I've just found a slightly more elegant (and less intrusive) fix. We >>>>>> can help the compiler to find the correct method by simply casting it >>>>>> to the correct version: >>>>>> >>>>>> diff -r be065f758154 >>>>>> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- >>>>> >>>>> complex-arabic-fallback.hh >>>>>> >>>>>> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh >>>>>> >>>>>> Thu Dec 14 12:49:47 2017 +0530 >>>>>> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh >>>>>> >>>>>> Thu Dec 14 17:11:49 2017 +0100 >>>>>> @@ -77,7 +77,7 @@ >>>>>> >>>>>> /* Bubble-sort or something equally good! >>>>>> * May not be good-enough for presidential candidate interviews, >>>>>> but good-enough for us... */ >>>>>> - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>>> >>>>> &substitutes[0]); >>>>>> >>>>>> + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID >>>>>> *, const OT::GlyphID *)) OT::GlyphID::cmp,&substitutes[0]); >>>>>> >>>>>> OT::Supplier glyphs_supplier (glyphs, >>>>>> num_glyphs); >>>>>> OT::Supplier substitutes_supplier (substitutes, >>>>> >>>>> num_glyphs); >>>>>> >>>>>> @@ -126,7 +126,7 @@ >>>>>> first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; >>>>>> num_first_glyphs++; >>>>>> } >>>>>> - hb_stable_sort (&first_glyphs[0], num_first_glyphs, >>>>>> OT::GlyphID::cmp,&first_glyphs_indirection[0]); >>>>>> >>>>>> + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const >>>>>> OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, >>>>>> &first_glyphs_indirection[0]); >>>>>> >>>>>> /* Now that the first-glyphs are sorted, walk again, populate >>>>>> ligatures. >>>> >>>> */ >>>>>> >>>>>> for (unsigned int i = 0; i< num_first_glyphs; i++) >>>>>> >>>>>> I'll also try to bring this change upstream into Harfbuzz, but we need >>>>>> to push this into the new jdk/jdk10 repo because there will be no more >>>>>> HarfBuzz integration for Java 10. >>>>>> >>>>>> Regards, >>>>>> Volker >>>>>> >>>>>> >>>>>> On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias >>>>>> wrote: >>>>>>> >>>>>>> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build >>>>>>> fails on >>>>>>> AIX. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I created the following bug : >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193515 >>>>>>> >>>>>>> >>>>>>> >>>>>>> The compile error we get on AIX (using XLC 12.1) is : >>>>>>> >>>>>>> >>>>>>> >>>>>>> === Output from failing command(s) repeated here === >>>>>>> >>>>>>> * For target >>>>>>> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- >>>>> >>>>> arabic.o: >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 80.3: 1540-0218 (S) The call does not match any parameter list >>>>>>> for >>>>>>> "hb_stable_sort". >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>> >>>>> private.hh", >>>>>>> >>>>>>> line 723.1: 1540-1283 (I) "template >>>>>>> hb_stable_sort(T *, >>>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>>> candidate. >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 80.43: 1540-0298 (I) Template argument deduction cannot be >>>>> >>>>> performed >>>>>>> >>>>>>> using the function "template int cmp(Type2) const". >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>> >>>>> private.hh", >>>>>>> >>>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>> >>>> unsigned >>>>>>> >>>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 80.3: 1540-0215 (I) The wrong number of arguments has been >>>>> >>>>> specified >>>>>>> >>>>>>> for "template hb_stable_sort(T *, unsigned int, int >>>>>>> (*)(const T >>>> >>>> *, >>>>>>> >>>>>>> const T *))". >>>>>>> >>>>>>> >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 129.3: 1540-0218 (S) The call does not match any parameter list >>>>>>> for >>>>>>> "hb_stable_sort". >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>> >>>>> private.hh", >>>>>>> >>>>>>> line 723.1: 1540-1283 (I) "template >>>>>>> hb_stable_sort(T *, >>>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>>> candidate. >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 129.55: 1540-0298 (I) Template argument deduction cannot be >>>>> >>>>> performed >>>>>>> >>>>>>> using the function "template int cmp(Type2) const". >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>> >>>>> private.hh", >>>>>>> >>>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>> >>>> unsigned >>>>>>> >>>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>>> >>>>>>> " >>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>> >>>>> shape-complex-arabic-fallback.hh", >>>>>>> >>>>>>> line 129.3: 1540-0215 (I) The wrong number of arguments has been >>>>> >>>>> specified >>>>>>> >>>>>>> for "template hb_stable_sort(T *, unsigned int, int >>>>>>> (*)(const T >>>> >>>> *, >>>>>>> >>>>>>> const T *))". >>>>>>> >>>>>>> >>>>>>> >>>>>>> The compilation ?complains? about the hb_stable_sort template used >>>> >>>> in >>>>>>> >>>>>>> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into >>>>>>> this , >>>>>>> the third parameter >>>>>>> >>>>>>> OT::GlyphID::cmp >>>>>>> >>>>>>> of >>>>>>> >>>>>>> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>>>>> &substitutes[0]); >>>>>>> >>>>>>> >>>>>>> >>>>>>> seems to trigger this XLC 12 issue . >>>>>>> >>>>>>> XLC 12 does not like the fact that we have two cmp functions (one a >>>>>>> template) in >>>>>>> >>>>>>> >>>>>>> >>>>>>> hb-open-type-private.hh : >>>>>>> >>>>>>> >>>>>>> >>>>>>> 610 template >>>>>>> >>>>>>> 611 struct IntType >>>>>>> >>>>>>> 612 { >>>>>>> >>>>>>> .... >>>>>>> >>>>>>> 617 static inline int cmp (const IntType *a, const >>>>>>> IntType *b) { return b->cmp (*a); } >>>>>>> >>>>>>> 622 >>>>>>> >>>>>>> 623 template >>>>>>> >>>>>>> 624 inline int cmp (Type2 a) const >>>>>>> >>>>>>> 625 { >>>>>>> >>>>>>> >>>>>>> >>>>>>> ( GlyphID is an IntType ) >>>>>>> >>>>>>> This looks like an XLC bug, however it is pretty easy to workaround >>>>>>> it by >>>>>>> using a helper compare-function with a unique name (issue with cmp >>>>>>> is >>>>> >>>>> that >>>>>>> >>>>>>> it is not unique, that confuses XLC ). >>>>>>> >>>>>>> See this webrev : >>>>>>> >>>>>>> >>>>>>> >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, Matthias From brian.burkhalter at oracle.com Tue Dec 19 19:28:35 2017 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Tue, 19 Dec 2017 11:28:35 -0800 Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: <96d526c3-7172-838a-6a10-d8956151bfbe@oracle.com> References: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> <96d526c3-7172-838a-6a10-d8956151bfbe@oracle.com> Message-ID: I concur but you might consider these changes to some verbiage: * PNGImageReader: L741 PNG specification -> ?The PNG specification? L744 ?PLTE chunk -> ?the PLTE chunk? L749-750 message -> ?Required PLTE chunk missing? * PngPLTEChunkMissingTest L64 Change message to match PNGImageReader lines 749-750. Thanks, Brian On Dec 18, 2017, at 11:03 PM, Sergey Bylokhov wrote: > The .02 version looks fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Wed Dec 20 12:03:51 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 20 Dec 2017 12:03:51 +0000 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update Message-ID: <68748446fd134947a235ea07828c6bdf@sap.com> Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From volker.simonis at gmail.com Thu Dec 21 14:05:50 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 21 Dec 2017 15:05:50 +0100 Subject: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 version fails to compile In-Reply-To: References: <0a0672a4fda64b06b4a3c523cbc2c443@sap.com> <65c25792-6336-59b6-b620-855bb298e814@oracle.com> <17ba51f208c445b9b81880a0051f76e6@sap.com> <5A37F9C8.8010500@oracle.com> Message-ID: FYI: my patch has been accepted and pushed upstream into Harfbuzz: Closed #655 https://github.com/harfbuzz/harfbuzz/issues/655 via #656 https://github.com/harfbuzz/harfbuzz/pull/656 On Tue, Dec 19, 2017 at 11:43 AM, Volker Simonis wrote: > Thanks Phil! > > I've just pushed this to jdk/jdk10. > > I've also opened an issue [1] in the upstream Harfbuzz project and > submitted a pull request with the fix [2]. > > So hopefully this won't be an issue with the next integration any more. > > Regards, > Volker > > [1] https://github.com/harfbuzz/harfbuzz/issues/655 > [2] https://github.com/harfbuzz/harfbuzz/pull/656 > > On Mon, Dec 18, 2017 at 6:24 PM, Philip Race wrote: >> +1 from me .. >> >> yes push to jdk/jdk10. >> >> -phil. >> >> >> On 12/18/17, 1:51 AM, Volker Simonis wrote: >>> >>> Hi Matthias, >>> >>> the change looks good and I can sponsor it. I'd just propose to >>> slightly change the comment to "..by the overloaded versions of 'cmp' >>> in IntType" if you don't mind. There's no need for a new webrew tough >>> - I can make that change before pushing. >>> >>> I'm just waiting for one more review from the 2D group. Afterwards >>> I'll push directly to jdk/jdk10. From my understanding, the fix will >>> than be automatically forward-integrated into jdk/jdk. >>> >>> Regards, >>> Volker >>> >>> >>> On Fri, Dec 15, 2017 at 2:24 PM, Baesken, Matthias >>> wrote: >>>> >>>> Hello, I created a second webrev : >>>> >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515.1/ >>>> >>>> >>>>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>>>> other platforms are guaranteed to be unaffected ? >>>> >>>> The new webrev uses the simpler cast-version proposed by Volki , and >>>> guards the AIX change by ifdef (suggested by Phil). >>>> >>>>>>> In the meantime we try to find out how latest xlC version 13 behaves . >>>> >>>> In the meantime I checked with XLC13 as well , but we see the error >>>> with XLC 13 too (same as XLC 12). >>>> >>>> Please review the change . >>>> >>>> It should go later into jdk10 as well (because jdk10 contains the new >>>> Harfbuzz 1.7.1 too ). >>>> >>>> >>>> Thanks, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Baesken, Matthias >>>>> Sent: Donnerstag, 14. Dezember 2017 18:03 >>>>> To: 'Phil Race'; Volker Simonis >>>>> >>>>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>>>> Subject: RE: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>>>> version fails to compile >>>>> >>>>> Hi Phil, hi Volki, >>>>> I think wrapping Volkis version into #ifdef _AIX >>>>> plus adding a small comment sounds like a good idea . >>>>> >>>>> In the meantime we try to find out how latest xlC version 13 behaves . >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Phil Race [mailto:philip.race at oracle.com] >>>>>> Sent: Donnerstag, 14. Dezember 2017 17:53 >>>>>> To: Volker Simonis; Baesken, Matthias >>>>>> >>>>>> Cc: Simonis, Volker; 2d-dev at openjdk.java.net >>>>>> Subject: Re: [OpenJDK 2D-Dev] RFR : 8193515 : AIX : new Harfbuzz 1.7.1 >>>>>> version fails to compile >>>>>> >>>>>> Whatever we do, can it be wrapped in an appropriate #ifdef AIX so that >>>>>> other platforms are guaranteed to be unaffected ? >>>>>> >>>>>> For upstream you can report it at github >>>>>> https://github.com/harfbuzz/harfbuzz >>>>>> and see how Behdad would like to handle it. >>>>>> >>>>>> I expect he would want it removed once the compiler bug is fixed. >>>>>> >>>>>> -pgil. >>>>>> >>>>>> On 12/14/2017 08:13 AM, Volker Simonis wrote: >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> thanks for addressing this issue! >>>>>>> >>>>>>> I'm pretty sure that his is a compiler bug and I have a short >>>>>>> reproducer which I'll send to IBM. >>>>>>> >>>>>>> The problem is that xlC can't distinguish a static member function >>>>>>> (which uses an ordinary function call) from a non-static member >>>>>>> function (which uses a member function call) with the same name. >>>>>>> >>>>>>> I've just found a slightly more elegant (and less intrusive) fix. We >>>>>>> can help the compiler to find the correct method by simply casting it >>>>>>> to the correct version: >>>>>>> >>>>>>> diff -r be065f758154 >>>>>>> src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot-shape- >>>>>> >>>>>> complex-arabic-fallback.hh >>>>>>> >>>>>>> --- a/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh >>>>>>> >>>>>>> Thu Dec 14 12:49:47 2017 +0530 >>>>>>> +++ b/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh >>>>>>> >>>>>>> Thu Dec 14 17:11:49 2017 +0100 >>>>>>> @@ -77,7 +77,7 @@ >>>>>>> >>>>>>> /* Bubble-sort or something equally good! >>>>>>> * May not be good-enough for presidential candidate interviews, >>>>>>> but good-enough for us... */ >>>>>>> - hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>>>> >>>>>> &substitutes[0]); >>>>>>> >>>>>>> + hb_stable_sort (&glyphs[0], num_glyphs, (int(*)(const OT::GlyphID >>>>>>> *, const OT::GlyphID *)) OT::GlyphID::cmp,&substitutes[0]); >>>>>>> >>>>>>> OT::Supplier glyphs_supplier (glyphs, >>>>>>> num_glyphs); >>>>>>> OT::Supplier substitutes_supplier (substitutes, >>>>>> >>>>>> num_glyphs); >>>>>>> >>>>>>> @@ -126,7 +126,7 @@ >>>>>>> first_glyphs_indirection[num_first_glyphs] = first_glyph_idx; >>>>>>> num_first_glyphs++; >>>>>>> } >>>>>>> - hb_stable_sort (&first_glyphs[0], num_first_glyphs, >>>>>>> OT::GlyphID::cmp,&first_glyphs_indirection[0]); >>>>>>> >>>>>>> + hb_stable_sort (&first_glyphs[0], num_first_glyphs, (int(*)(const >>>>>>> OT::GlyphID *, const OT::GlyphID *)) OT::GlyphID::cmp, >>>>>>> &first_glyphs_indirection[0]); >>>>>>> >>>>>>> /* Now that the first-glyphs are sorted, walk again, populate >>>>>>> ligatures. >>>>> >>>>> */ >>>>>>> >>>>>>> for (unsigned int i = 0; i< num_first_glyphs; i++) >>>>>>> >>>>>>> I'll also try to bring this change upstream into Harfbuzz, but we need >>>>>>> to push this into the new jdk/jdk10 repo because there will be no more >>>>>>> HarfBuzz integration for Java 10. >>>>>>> >>>>>>> Regards, >>>>>>> Volker >>>>>>> >>>>>>> >>>>>>> On Thu, Dec 14, 2017 at 4:10 PM, Baesken, Matthias >>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, after upgrading to new Harfbuzz 1.7.1 the openjdk build >>>>>>>> fails on >>>>>>>> AIX. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I created the following bug : >>>>>>>> >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8193515 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The compile error we get on AIX (using XLC 12.1) is : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> === Output from failing command(s) repeated here === >>>>>>>> >>>>>>>> * For target >>>>>>>> support_native_java.desktop_libfontmanager_hb-ot-shape-complex- >>>>>> >>>>>> arabic.o: >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 80.3: 1540-0218 (S) The call does not match any parameter list >>>>>>>> for >>>>>>>> "hb_stable_sort". >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>>> >>>>>> private.hh", >>>>>>>> >>>>>>>> line 723.1: 1540-1283 (I) "template >>>>>>>> hb_stable_sort(T *, >>>>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>>>> candidate. >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 80.43: 1540-0298 (I) Template argument deduction cannot be >>>>>> >>>>>> performed >>>>>>>> >>>>>>>> using the function "template int cmp(Type2) const". >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>>> >>>>>> private.hh", >>>>>>>> >>>>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>>> >>>>> unsigned >>>>>>>> >>>>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 80.3: 1540-0215 (I) The wrong number of arguments has been >>>>>> >>>>>> specified >>>>>>>> >>>>>>>> for "template hb_stable_sort(T *, unsigned int, int >>>>>>>> (*)(const T >>>>> >>>>> *, >>>>>>>> >>>>>>>> const T *))". >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 129.3: 1540-0218 (S) The call does not match any parameter list >>>>>>>> for >>>>>>>> "hb_stable_sort". >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>>> >>>>>> private.hh", >>>>>>>> >>>>>>>> line 723.1: 1540-1283 (I) "template >>>>>>>> hb_stable_sort(T *, >>>>>>>> unsigned int, int (*)(const T *, const T *), T2 *)" is not a viable >>>>>>>> candidate. >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 129.55: 1540-0298 (I) Template argument deduction cannot be >>>>>> >>>>>> performed >>>>>>>> >>>>>>>> using the function "template int cmp(Type2) const". >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb- >>>>>> >>>>>> private.hh", >>>>>>>> >>>>>>>> line 748.1: 1540-1283 (I) "template hb_stable_sort(T *, >>>>> >>>>> unsigned >>>>>>>> >>>>>>>> int, int (*)(const T *, const T *))" is not a viable candidate. >>>>>>>> >>>>>>>> " >>>>>>>> /jdk/src/java.desktop/share/native/libfontmanager/harfbuzz/hb-ot- >>>>>> >>>>>> shape-complex-arabic-fallback.hh", >>>>>>>> >>>>>>>> line 129.3: 1540-0215 (I) The wrong number of arguments has been >>>>>> >>>>>> specified >>>>>>>> >>>>>>>> for "template hb_stable_sort(T *, unsigned int, int >>>>>>>> (*)(const T >>>>> >>>>> *, >>>>>>>> >>>>>>>> const T *))". >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The compilation ?complains? about the hb_stable_sort template used >>>>> >>>>> in >>>>>>>> >>>>>>>> hb-ot-shape-complex-arabic-fallback.hh . After looking a bit into >>>>>>>> this , >>>>>>>> the third parameter >>>>>>>> >>>>>>>> OT::GlyphID::cmp >>>>>>>> >>>>>>>> of >>>>>>>> >>>>>>>> hb_stable_sort (&glyphs[0], num_glyphs, OT::GlyphID::cmp, >>>>>>>> &substitutes[0]); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> seems to trigger this XLC 12 issue . >>>>>>>> >>>>>>>> XLC 12 does not like the fact that we have two cmp functions (one a >>>>>>>> template) in >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> hb-open-type-private.hh : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 610 template >>>>>>>> >>>>>>>> 611 struct IntType >>>>>>>> >>>>>>>> 612 { >>>>>>>> >>>>>>>> .... >>>>>>>> >>>>>>>> 617 static inline int cmp (const IntType *a, const >>>>>>>> IntType *b) { return b->cmp (*a); } >>>>>>>> >>>>>>>> 622 >>>>>>>> >>>>>>>> 623 template >>>>>>>> >>>>>>>> 624 inline int cmp (Type2 a) const >>>>>>>> >>>>>>>> 625 { >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ( GlyphID is an IntType ) >>>>>>>> >>>>>>>> This looks like an XLC bug, however it is pretty easy to workaround >>>>>>>> it by >>>>>>>> using a helper compare-function with a unique name (issue with cmp >>>>>>>> is >>>>>> >>>>>> that >>>>>>>> >>>>>>>> it is not unique, that confuses XLC ). >>>>>>>> >>>>>>>> See this webrev : >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8193515/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review it. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks, Matthias From matthias.baesken at sap.com Thu Dec 21 15:13:07 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 21 Dec 2017 15:13:07 +0000 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: <68748446fd134947a235ea07828c6bdf@sap.com> References: <68748446fd134947a235ea07828c6bdf@sap.com> Message-ID: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From gromero at linux.vnet.ibm.com Fri Dec 22 13:52:36 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 22 Dec 2017 11:52:36 -0200 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: References: Message-ID: <5A3D0E24.5010509@linux.vnet.ibm.com> Hi Matthias, png_init_filter_functions_vsx() is implemented in: https://sourceforge.net/p/libpng/code/ci/libpng16/tree/powerpc/powerpc_init.c#l53 Looks like the two files found in: https://sourceforge.net/p/libpng/code/ci/libpng16/tree/powerpc/ are not merged. If you include them, for instance: http://cr.openjdk.java.net/~gromero/misc/libpnp_powerpc_missingfiles.diff the issue is resolved (on PPC64 at least - probably we have to adapt the build for not breaking it on other archs?. Also I'm not sure if the optimized code will kick in just by including the missing files). However I could not find the Intel intrinsics [1] as well imported to OpenJDK tree. Is that intentional? I mean, shouldn't we enable optimization when it's available? Best regards, Gustavo [1] https://sourceforge.net/p/libpng/code/ci/libpng16/tree/intel/ From philip.race at oracle.com Fri Dec 22 18:07:52 2017 From: philip.race at oracle.com (Phil Race) Date: Fri, 22 Dec 2017 10:07:52 -0800 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: References: <68748446fd134947a235ea07828c6bdf@sap.com> Message-ID: I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: > > >Do you have a version of libpng available that contains the missing function > png_init_filter_functions_vsx ? > > >Or do you have an idea where it should come from (I cannot find it in the main libpng > sources). > > >To fix the build, we could probably disable the part bringing in > png_init_filter_functions_vsx in png_init_filter_functions_vsx . > > Hello, small update - here is a fix that disables the libpng vsx > optimizations on ppc64 (and fixes the build issue). > > Should I prepare a webrev ? Or how to get a ppc64 le / be > png_init_filter_functions_vsx implementation ? > > Best regards, Matthias > > ----------------------- > > diff -r d55bee3727de > src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > > --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Tue Dec 19 17:31:53 2017 -0500 > > +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Wed Dec 20 17:16:01 2017 +0100 > > @@ -220,12 +220,15 @@ > > # endif > > #endif > > +/* for now avoid the ppc64 vsx optimizations */ > > #ifndef PNG_POWERPC_VSX_OPT > > -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) > > -# define PNG_POWERPC_VSX_OPT 2 > > -# else > > +/* > > + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) > > + * # define PNG_POWERPC_VSX_OPT 2 > > + * # else > > + */ > > # define PNG_POWERPC_VSX_OPT 0 > > -# endif > > +/* # endif */ > > #endif > > #ifndef PNG_INTEL_SSE_OPT > > ----------------------- > > *From:*Baesken, Matthias > *Sent:* Mittwoch, 20. Dezember 2017 13:04 > *To:* Phil Race (philip.race at oracle.com) > *Cc:* Doerr, Martin ; Simonis, Volker > ; 2d-dev at openjdk.java.net > *Subject:* jdk-hs ppc64le build error, probably related to libpng update > > Hi Phil, it looks like the recent png lib change > > 8183960: Upgrade to libpng 1.6.34 > > http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 > > +#if PNG_POWERPC_VSX_OPT > 0 > > +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx > > +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 > > +#endif > > Causes build errors in our linuxppc64le openjdk jdk-hs > (fast)dbg build . > > We get this linker error : > > pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > > Do you have a version of libpng available that contains the > missing function png_init_filter_functions_vsx ? > > Or do you have an idea where it should come from (I cannot find it in > the main libpng sources). > > To fix the build, we could probably disable the part bringing in > png_init_filter_functions_vsx in png_init_filter_functions_vsx . > > Thanks, Matthias > > Error message : > > * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In > function `png_read_filter_row': > * pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > * collect2: error: ld returned 1 exit status > * Awt2dLibraries.gmk:928: recipe for target > '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Dec 26 07:48:35 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 25 Dec 2017 23:48:35 -0800 (PST) Subject: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing In-Reply-To: References: <908e994a-9f16-4109-b37a-6b010ac14cbb@default> <96d526c3-7172-838a-6a10-d8956151bfbe@oracle.com> Message-ID: Hi Brian, Thanks for your inputs. I have made changes mentioned by you and will check-in code with your changes. Please find updated webrev for reference: http://cr.openjdk.java.net/~jdv/8190997/webrev.03/ Thanks, Jay From: Brian Burkhalter Sent: Wednesday, December 20, 2017 12:59 AM To: Jayathirth D V Cc: Sergey Bylokhov; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [10] RFR JDK-8190997: PNGImageReader throws NullPointerException when PLTE section is missing I concur but you might consider these changes to some verbiage: * PNGImageReader: L741 PNG specification -> "The PNG specification" L744 "PLTE chunk -> "the PLTE chunk" L749-750 message -> "Required PLTE chunk missing" * PngPLTEChunkMissingTest L64 Change message to match PNGImageReader lines 749-750. Thanks, Brian On Dec 18, 2017, at 11:03 PM, Sergey Bylokhov wrote: The .02 version looks fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Thu Dec 28 10:12:49 2017 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 28 Dec 2017 02:12:49 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> Message-ID: <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> Hi Prahalad, Thanks for your valuable inputs. Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, December 19, 2017 3:08 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello Jay Good day to you. I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. Here is a simple math that considers the worst case scenario with max values: . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- max_width : (2 ^ 31) - 1 = 2147483647 max_input_bands = 4 max_bit_depth = 16 (2 Bytes) . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. // Fits into "long" data type max_bits_per_row = max_width * max_input_bands * max_bit_depth = 2147483647 x 4 x 16 = 137438953408 // Does not fit into "int" data type max_bytes_per_row = max_bits_per_row + 7 / 8 = 17179869176 = (0x 3FFFFFFF8 - Goes beyond 4B boundary) // Upon division by 2 for 16-bit images max_elts_per_row = max_bytes_per_row / 2 = 8589934588 = (0x 1FFFFFFFC - Goes beyond 4B boundary) . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Thursday, December 14, 2017 1:48 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello All, Please review the following fix in JDK : Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". Exception in thread "main" java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride ??????????????? at java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelInterleavedSampleModel.java:101) ??????????????? at java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java:642) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(PNGImageReader.java:974) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1099) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1295) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1420) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1699) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) ??????????????? at PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java:50) Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. Thanks, Jay From matthias.baesken at sap.com Thu Dec 28 13:07:18 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 28 Dec 2017 13:07:18 +0000 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: References: <68748446fd134947a235ea07828c6bdf@sap.com> Message-ID: Hi Phil, I think your idea to guard with #ifdef PNG_POWERPC_VSX_API_SUPPORTED Is fine, should I prepare a webrev using this guard ? * Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. Yes it is a good idea to report this upstream as well at libpng. Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 22. Dezember 2017 19:08 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Dec 28 17:08:54 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 28 Dec 2017 09:08:54 -0800 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: References: <68748446fd134947a235ea07828c6bdf@sap.com> Message-ID: <5A452526.3080906@oracle.com> This all sounds fine to me. Definitely we should report this upstream to see what they say but clearly we aren't bound to wait for an answer from there since this is a build breakage for PPC. If someone upstream comes back with a better answer we can update the fix. I think this png update will get backported to 8u at some point .. the PPC port is supported on 8u, isn't it ? So we'll want to make sure we have the fix before we do the backport. -phil. On 12/28/17, 5:07 AM, Baesken, Matthias wrote: > > Hi Phil, I think your idea to guard with > > #ifdef PNG_POWERPC_VSX_API_SUPPORTED > > Is fine, should I prepare a webrev using this guard ? > > * Wrapping in that check might be OK (for > PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this > upstream. > > Yes it is a good idea to report this upstream as well at libpng. > > Best regards, Matthias > > *From:*Phil Race [mailto:philip.race at oracle.com] > *Sent:* Freitag, 22. Dezember 2017 19:08 > *To:* Baesken, Matthias ; > 2d-dev at openjdk.java.net > *Cc:* Doerr, Martin ; Simonis, Volker > > *Subject:* Re: jdk-hs ppc64le build error, probably related to libpng > update > > I expect that will fix it but I wonder if the problem is that all of > this needs > to be guarded by checking :- > > #ifdef PNG_POWERPC_VSX_API_SUPPORTED > > It looks to me configure would have set that if it had been run on PPC AND > you have passed --enable-powerpc-vsx to configure > > But of course I did not. > > And someone can set it unsupported anyway. > > So this seems like a libpng bug. > > Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but > you'll want to report this upstream. > > I have no intention of pulling in the accelerated code .. even for > intel ... this > library is used only for splashscreen. > > -phil. > > > On 12/21/2017 07:13 AM, Baesken, Matthias wrote: > > >Do you have a version of libpng available that contains the > missing function png_init_filter_functions_vsx ? > > >Or do you have an idea where it should come from (I cannot find it > in the main libpng sources). > > >To fix the build, we could probably disable the part bringing in > png_init_filter_functions_vsx in png_init_filter_functions_vsx . > > Hello, small update - here is a fix that disables the libpng > vsx optimizations on ppc64 (and fixes the build issue). > > Should I prepare a webrev ? Or how to get a ppc64 le / be > png_init_filter_functions_vsx implementation ? > > Best regards, Matthias > > ----------------------- > > diff -r d55bee3727de > src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > > --- > a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue > Dec 19 17:31:53 2017 -0500 > > +++ > b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h > Wed Dec 20 17:16:01 2017 +0100 > > @@ -220,12 +220,15 @@ > > # endif > > #endif > > +/* for now avoid the ppc64 vsx optimizations */ > > #ifndef PNG_POWERPC_VSX_OPT > > -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) > > -# define PNG_POWERPC_VSX_OPT 2 > > -# else > > +/* > > + * # if defined(__PPC64__) && defined(__ALTIVEC__) && > defined(__VSX__) > > + * # define PNG_POWERPC_VSX_OPT 2 > > + * # else > > + */ > > # define PNG_POWERPC_VSX_OPT 0 > > -# endif > > +/* # endif */ > > #endif > > #ifndef PNG_INTEL_SSE_OPT > > ----------------------- > > *From:*Baesken, Matthias > *Sent:* Mittwoch, 20. Dezember 2017 13:04 > *To:* Phil Race (philip.race at oracle.com > ) > > *Cc:* Doerr, Martin > ; Simonis, Volker > ; > 2d-dev at openjdk.java.net > *Subject:* jdk-hs ppc64le build error, probably related to libpng > update > > Hi Phil, it looks like the recent png lib change > > 8183960: Upgrade to libpng 1.6.34 > > http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 > > +#if PNG_POWERPC_VSX_OPT > 0 > > +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx > > +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 > > +#endif > > Causes build errors in our linuxppc64le openjdk jdk-hs > (fast)dbg build . > > We get this linker error : > > pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > > Do you have a version of libpng available that contains the > missing function png_init_filter_functions_vsx ? > > Or do you have an idea where it should come from (I cannot find it > in the main libpng sources). > > To fix the build, we could probably disable the part bringing in > png_init_filter_functions_vsx in png_init_filter_functions_vsx . > > Thanks, Matthias > > Error message : > > * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In > function `png_read_filter_row': > * pngrutil.c:(.text+0x4824): undefined reference to > `png_init_filter_functions_vsx' > * collect2: error: ld returned 1 exit status > * Awt2dLibraries.gmk:928: recipe for target > '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Fri Dec 29 06:49:19 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Thu, 28 Dec 2017 22:49:19 -0800 (PST) Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper In-Reply-To: <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> References: <6639d1ae-fa52-4505-af5f-1bf3e114fbe5@default> <4903dfdb-8c64-4a38-95e2-549f26b3ee41@default> <045c7f01-106f-4f01-a661-a82ab15c1b1c@default> Message-ID: <74518345-8ed6-44da-b384-01802c01368c@default> Hello Jay Good day to you. The code changes wrap the IllegalArgumentException in IIOException. This approach is better & aligns with how OutOfMemoryError was wrapped to fix JDK-8190332. The only point that I 'm not sure is- whether we could wrap IllegalArgumentException twice before throwing to the user code. javax.imageio.IIOException: Error reading PNG image data at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read at java.desktop/javax.imageio.ImageIO.read ... Caused by: javax.imageio.IIOException: Caught exception during read: at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage ... Caused by: java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride at java.desktop/java.awt.image.PixelInterleavedSampleModel. at java.desktop/java.awt.image.Raster.createInterleavedRaster at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster Since there are multiple levels of same exception, programmer could have trouble getting the cause using getCause() method. However, Invoking printStackTrace() on the outer most exception object gives complete call stack (as listed above). So I think, this should be ok. I would like to know of others' opinion too. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, December 28, 2017 3:43 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hi Prahalad, Thanks for your valuable inputs. Even though the fix resolves the issue for the particular test case we have it will not solve the buffer overflow problem as you have mentioned in highest limit case or many other cases where the computed value is very high. Also we cannot change datatype of bytesPerRow/eltsPerRow as they are used in many passed to many other Raster and Stream API's. The best approach to resolve this issue would be to wrap the Exception that we are getting while creating Raster/SampleModel into an IIOException as we have done in https://bugs.openjdk.java.net/browse/JDK-8190332 . By doing this we will abide by specification and also we will have complete stack of why we got the exception so that it can be debugged properly in future. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/8191174/webrev.01/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Tuesday, December 19, 2017 3:08 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello Jay Good day to you. I don't think it's possible to fix this issue despite having intermediate " long " variable to hold intermediate bits per pixel. Here is a simple math that considers the worst case scenario with max values: . As per the PNG specification, the maximum permissible width, number of bands, bit-depth are as follows- max_width : (2 ^ 31) - 1 = 2147483647 max_input_bands = 4 max_bit_depth = 16 (2 Bytes) . As per the logic proposed in the fix, the intermediate bits per row would fit into a "long" variable but bytes per pixel would not fit into "int" variable. // Fits into "long" data type max_bits_per_row = max_width * max_input_bands * max_bit_depth = 2147483647 x 4 x 16 = 137438953408 // Does not fit into "int" data type max_bytes_per_row = max_bits_per_row + 7 / 8 = 17179869176 = (0x 3FFFFFFF8 - Goes beyond 4B boundary) // Upon division by 2 for 16-bit images max_elts_per_row = max_bytes_per_row / 2 = 8589934588 = (0x 1FFFFFFFC - Goes beyond 4B boundary) . If we intend to store bytes per row (and eltsPerRow which is scanline stride) in a "long" variable, the same cannot be sent to Raster APIs because the APIs accept "int" type for scanline stride in arguments list. Going by the Raster APIs used in PNGImageReader, a proper fix would require changes to its APIs as well to handle such large scanline stride values. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Jayathirth D V Sent: Thursday, December 14, 2017 1:48 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] RFR JDK-8191174: PngReader throws IllegalArgumentException because ScanlineStride calculation logic is not proper Hello All, Please review the following fix in JDK : Bug : https://bugs.openjdk.java.net/browse/JDK-8191174 Webrev : http://cr.openjdk.java.net/~jdv/8191174/webrev.00/ Issue : When we try to read PNG image with large width we throw undocumented IllegalArgumentException with message "Pixel stride times width must be less than or equal to the scanline stride". Exception in thread "main" java.lang.IllegalArgumentException: Pixel stride times width must be less than or equal to the scanline stride ??????????????? at java.desktop/java.awt.image.PixelInterleavedSampleModel.(PixelInterleavedSampleModel.java:101) ??????????????? at java.desktop/java.awt.image.Raster.createInterleavedRaster(Raster.java:642) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.createRaster(PNGImageReader.java:974) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodePass(PNGImageReader.java:1099) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.decodeImage(PNGImageReader.java:1295) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.readImage(PNGImageReader.java:1420) ??????????????? at java.desktop/com.sun.imageio.plugins.png.PNGImageReader.read(PNGImageReader.java:1699) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1468) ??????????????? at java.desktop/javax.imageio.ImageIO.read(ImageIO.java:1363) ??????????????? at PngReaderLargeWidthStrideTest.main(PngReaderLargeWidthStrideTest.java:50) Root cause : We use large width present in IHDR and calculate elements per row which is passed as scanlinestride for creating the required raster and its corresponding sample model. ?When the call reaches creation of PixelInterleavedSampleModel it checks the condition of (pixelStride * w) > scanlineStride. Since in our case we pass this condition it throws IllegalArgumentException. We have invalid scanlineStride value because when we calculate elements per row/bytes per row value in PNGImageReader the integer variable buffer is overflowed and we maintain invalid value for bytesPerRow. Solution : We can maintain the intermediate bitsPerRow value in long datatype and calculate bytesPerRow using the long value and then typecast it to int bytesPerRow variable. By doing this we will maintain the required scanlineStride/eltsPerRow value properly. After this solution we will throw proper IIOException because of changes present in JDK-8190332 and not the undocumented IllegalArgumentException. Thanks, Jay From prahalad.kumar.narayanan at oracle.com Fri Dec 29 11:00:24 2017 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 29 Dec 2017 03:00:24 -0800 (PST) Subject: [OpenJDK 2D-Dev] [11] RFR: [JDK-5064835] TextMeasurer/deleteChar function fails when deleting more than one characters Message-ID: <4c4a1107-5c91-4307-a467-715ea8ca992c@default> Hello Everyone Good day to you. Request your time in reviewing the fix for the bug: JDK-5064835 TextMeasurer/deleteChar function fails when deleting more than one characters. Root Cause: . The spec clearly mentions that the concerned method is to be used to delete a single character. . However, the spec does not mention the outcome when the method is used to delete multiple characters (as reported in the bug) Solution Approaches: . Since the spec does not mention the outcome when multiple characters are deleted, the result is left to the implementation. . The solution can be approached in two perspectives- 1. Update the spec to explicitly mention the exception that would be thrown in such cases or 2. Re-initialize the TextMeasurer with the new text as present in the argument of the method. Solution: . I inspected feasibility/ risk of both the approaches and I 'm of the opinion that approach 1. is better. . Reason is that, with the second approach- . The re-initialization would reset all text attributes, and state variabes that were set on TextMeasurer (and internal StyledParagraph) object. . If re-initialization is required, one could create a new TextMeasurer using the modified text rather than invoking deleteChar method. . Thus in the proposed solution- I 've added a throws clause that explicitly mentions that IllegalArgumentException will be thrown when attempted to delete multiple characters. Other Info: . The fix was tested with existing jtreg test cases- No regressions were seen. . 2 JCK tests have been found to fail. They are- . java_awt/Font/TextMeasurer/CharTest (TestCase5) . java_awt/Font/LineBreakMeasurer/CharTest (TestCase4) . In both the failures, incorrect arguments are passed to deleteChar method- newParagraph (with multiple chars deleted) & beginIndex (-1) . While the test case expects index out of bounds exception for -ve index, the code now throws IllegalArgumentsException. . A minor correction to JCK test will fix the issue. I shall raise a JCK bug once the fix is approved & submitted. Kindly review the changes at your convenience & share your feedback: http://cr.openjdk.java.net/~pnarayanan/5064835/webrev.00/ Note: I 've not raised a CSR for this bug yet. Based on review, I will create the CSR for change to the specification. Thank you for your time in review & Happy New Year Prahalad N. From martin.doerr at sap.com Thu Dec 28 17:34:24 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 28 Dec 2017 17:34:24 -0000 Subject: [OpenJDK 2D-Dev] jdk-hs ppc64le build error, probably related to libpng update In-Reply-To: <5A452526.3080906@oracle.com> References: <68748446fd134947a235ea07828c6bdf@sap.com> <5A452526.3080906@oracle.com> Message-ID: Hi Phil, do you know anybody we can contact for reporting the issue upstream? Yes, 8u is supported on PPC64, so we need the fix before backporting. Thanks a lot and best regards, Martin From: Philip Race [mailto:philip.race at oracle.com] Sent: Donnerstag, 28. Dezember 2017 18:09 To: Baesken, Matthias Cc: 2d-dev at openjdk.java.net; Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update This all sounds fine to me. Definitely we should report this upstream to see what they say but clearly we aren't bound to wait for an answer from there since this is a build breakage for PPC. If someone upstream comes back with a better answer we can update the fix. I think this png update will get backported to 8u at some point .. the PPC port is supported on 8u, isn't it ? So we'll want to make sure we have the fix before we do the backport. -phil. On 12/28/17, 5:07 AM, Baesken, Matthias wrote: Hi Phil, I think your idea to guard with #ifdef PNG_POWERPC_VSX_API_SUPPORTED Is fine, should I prepare a webrev using this guard ? * Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. Yes it is a good idea to report this upstream as well at libpng. Best regards, Matthias From: Phil Race [mailto:philip.race at oracle.com] Sent: Freitag, 22. Dezember 2017 19:08 To: Baesken, Matthias ; 2d-dev at openjdk.java.net Cc: Doerr, Martin ; Simonis, Volker Subject: Re: jdk-hs ppc64le build error, probably related to libpng update I expect that will fix it but I wonder if the problem is that all of this needs to be guarded by checking :- #ifdef PNG_POWERPC_VSX_API_SUPPORTED It looks to me configure would have set that if it had been run on PPC AND you have passed --enable-powerpc-vsx to configure But of course I did not. And someone can set it unsupported anyway. So this seems like a libpng bug. Wrapping in that check might be OK (for PNG_POWERPC_VSX_API_SUPPORTED) but you'll want to report this upstream. I have no intention of pulling in the accelerated code .. even for intel ... this library is used only for splashscreen. -phil. On 12/21/2017 07:13 AM, Baesken, Matthias wrote: >Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? >Or do you have an idea where it should come from (I cannot find it in the main libpng sources). >To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Hello, small update - here is a fix that disables the libpng vsx optimizations on ppc64 (and fixes the build issue). Should I prepare a webrev ? Or how to get a ppc64 le / be png_init_filter_functions_vsx implementation ? Best regards, Matthias ----------------------- diff -r d55bee3727de src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h --- a/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Tue Dec 19 17:31:53 2017 -0500 +++ b/src/java.desktop/share/native/libsplashscreen/libpng/pngpriv.h Wed Dec 20 17:16:01 2017 +0100 @@ -220,12 +220,15 @@ # endif #endif +/* for now avoid the ppc64 vsx optimizations */ #ifndef PNG_POWERPC_VSX_OPT -# if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) -# define PNG_POWERPC_VSX_OPT 2 -# else +/* + * # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__) + * # define PNG_POWERPC_VSX_OPT 2 + * # else + */ # define PNG_POWERPC_VSX_OPT 0 -# endif +/* # endif */ #endif #ifndef PNG_INTEL_SSE_OPT ----------------------- From: Baesken, Matthias Sent: Mittwoch, 20. Dezember 2017 13:04 To: Phil Race (philip.race at oracle.com) Cc: Doerr, Martin ; Simonis, Volker ; 2d-dev at openjdk.java.net Subject: jdk-hs ppc64le build error, probably related to libpng update Hi Phil, it looks like the recent png lib change 8183960: Upgrade to libpng 1.6.34 http://hg.openjdk.java.net/jdk/hs/rev/791d551bcdb8 +#if PNG_POWERPC_VSX_OPT > 0 +# define PNG_FILTER_OPTIMIZATIONS png_init_filter_functions_vsx +# define PNG_POWERPC_VSX_IMPLEMENTATION 1 +#endif Causes build errors in our linuxppc64le openjdk jdk-hs (fast)dbg build . We get this linker error : pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' Do you have a version of libpng available that contains the missing function png_init_filter_functions_vsx ? Or do you have an idea where it should come from (I cannot find it in the main libpng sources). To fix the build, we could probably disable the part bringing in png_init_filter_functions_vsx in png_init_filter_functions_vsx . Thanks, Matthias Error message : * /hs/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_read_filter_row': * pngrutil.c:(.text+0x4824): undefined reference to `png_init_filter_functions_vsx' * collect2: error: ld returned 1 exit status * Awt2dLibraries.gmk:928: recipe for target '/hs/support/modules_libs/java.desktop/libsplashscreen.so' failed -------------- next part -------------- An HTML attachment was scrubbed... URL: