From krishna.addepalli at oracle.com Mon Apr 2 04:26:01 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sun, 1 Apr 2018 21:26:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <145db2fc-516f-4602-be90-210985690f22@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> Message-ID: <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Apr 2 06:03:29 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Sun, 1 Apr 2018 23:03:29 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> Message-ID: Hi Krishna, The constant values for different color types is : static final int PNG_COLOR_GRAY = 0; static final int PNG_COLOR_RGB = 2; static final int PNG_COLOR_PALETTE = 3; static final int PNG_COLOR_GRAY_ALPHA = 4; static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From krishna.addepalli at oracle.com Mon Apr 2 06:10:01 2018 From: krishna.addepalli at oracle.com (Krishna Addepalli) Date: Sun, 1 Apr 2018 23:10:01 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> Message-ID: <985951de-1413-4744-901d-cf3ea1cc88c7@default> Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : static final int PNG_COLOR_GRAY = 0; static final int PNG_COLOR_RGB = 2; static final int PNG_COLOR_PALETTE = 3; static final int PNG_COLOR_GRAY_ALPHA = 4; static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Mon Apr 2 06:33:22 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Sun, 1 Apr 2018 23:33:22 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <985951de-1413-4744-901d-cf3ea1cc88c7@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> Message-ID: Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From jayathirth.d.v at oracle.com Mon Apr 2 07:58:43 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 2 Apr 2018 00:58:43 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <985951de-1413-4744-901d-cf3ea1cc88c7@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> Message-ID: <234c1827-0a3c-47ee-b391-3389aa25ca22@default> Hi Krishna, I verified usage of tRNS_colorType values in PNGImageRader, PNGImageWriter & PNGMetadata. We are using tRNS_coloType only when they are of type RGB, PALETTE or GRAY only in conjunction with tRNS_present variable. There are no places where undefined tRNS_colorType is used. Thanks for your suggestion to use constant variable for undefined colorType. I have made appropriate changes for the same. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.04/ I also see that Prahalad has given suggestions over webrev.03, I will go through them and update accordingly later. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : static final int PNG_COLOR_GRAY = 0; static final int PNG_COLOR_RGB = 2; static final int PNG_COLOR_PALETTE = 3; static final int PNG_COLOR_GRAY_ALPHA = 4; static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: Return ((destinationBands == null || destinationBands.length == 4) && metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { byteData[destidx] = curr[srcidx]; byteData[destidx + 1] = curr[srcidx + 1]; byteData[destidx + 2] = curr[srcidx + 2]; if (curr[srcidx] == (byte)metadata.tRNS_red && curr[srcidx + 1] == (byte)metadata.tRNS_green && curr[srcidx + 2] == (byte)metadata.tRNS_blue) { byteData[destidx + 3] = (byte)0; } else { byteData[destidx + 3] = (byte)255; } srcidx += 3; destidx += 4; } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Tue Apr 3 09:48:28 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 3 Apr 2018 11:48:28 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: On 2018-03-27 18:44, Phil Race wrote: > As I said I prefer the make file change, since this is a change to an > upstream library. Newtons fourth law: For every reviewer, there's an equal and opposite reviewer. :) Here I am, advocating a source code fix. As Thomas says, the compiler complaint seems reasonable, and disabling it might cause us to miss other future errors. Why can't we push the source code fix, and also submit it upstream? /Magnus > I've looked at jpeg-9c and it still looks identical to what we have in > 6b, so this code > seems to have stood the test of time. I'm also unclear why the > compiler would > complain about that and not the one a few lines later > > 819 while (bits[i] == 0) /* find largest codelength still in use */ > 820 i--; > > A push to jchuff.c will get blown away if/when we upgrade. > A tool-chain specific fix in the makefile with an appropriate comment is more targeted. > > -phil. > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: >> Hi all, >> >> just a friendly reminder. I would like to push this tiny fix because >> tripping over this on our linux s390x builds is annoying (yes, we can >> maintain patch queues, but this is a constant error source). >> >> I will wait for 24 more hours until a reaction. If no serious >> objections are forcoming, I want to push it (tier1 tests ran thru, >> and me and Christoph langer are both Reviewers). >> >> Thanks! Thomas >> >> On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe >> > wrote: >> >> Hi all, >> >> may I please have another review for this really trivial change. >> It fixes a gcc warning on s390 and ppc. Also, it is probably a >> good idea to fix this. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8200052 >> >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ >> >> >> This was contributed by Adam Farley at IBM. >> >> I already reviewed this. I also test-built on zlinux and it works. >> >> Thanks, Thomas >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Tue Apr 3 12:07:22 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Tue, 3 Apr 2018 13:07:22 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: I also advocate the source code fix, as Make isn't meant to use the sort of logic required to properly analyse the toolchain version string. e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and Make doesn't seem to do substring stuff unless you mess around with shells. Plus, as people have said, it's better to solve problem x (or work around a specific instance of x) than to ignore the exception, even if the ignoring code is toolchain- specific. - Adam Farley > On 2018-03-27 18:44, Phil Race wrote: > >> As I said I prefer the make file change, since this is a change to an upstream library. > > Newtons fourth law: For every reviewer, there's an equal and opposite reviewer. :) > > Here I am, advocating a source code fix. As Thomas says, the compiler complaint seems reasonable, and disabling it might cause us to miss other future errors. > > Why can't we push the source code fix, and also submit it upstream? > > /Magnus > > > I've looked at jpeg-9c and it still looks identical to what we have in 6b, so this code > seems to have stood the test of time. I'm also unclear why the compiler would > complain about that and not the one a few lines later > > > 819 while (bits[i] == 0) /* find largest codelength still in use */ > 820 i--; > > A push to jchuff.c will get blown away if/when we upgrade. > A tool-chain specific fix in the makefile with an appropriate comment is more targeted. > > > -phil. > > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > Hi all, > > > just a friendly reminder. I would like to push this tiny fix because tripping over this on our linux s390x builds is annoying (yes, we can maintain patch queues, but this is a constant error source). > > > I will wait for 24 more hours until a reaction. If no serious objections are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph langer are both Reviewers). > > > Thanks! Thomas > > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe wrote: > > Hi all, > > > may I please have another review for this really trivial change. It fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix this. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > This was contributed by Adam Farley at IBM. > > > I already reviewed this. I also test-built on zlinux and it works. > > > Thanks, Thomas > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Apr 3 21:26:16 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 3 Apr 2018 14:26:16 -0700 Subject: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out In-Reply-To: References: Message-ID: <55f4bed7-c603-5186-91c0-9214cec56430@oracle.com> Looks fine. On 30/03/2018 13:09, Laurent Bourg?s wrote: > Phil, > Here is the ClipShapeTest change to fix timeout issue > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200526 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8200526.0/ > > I increased the timeout to 300s per test. > > I did a jtreg run on my machine (slowed down to 2Ghz) and it passed > successfully although the ClipShapeTest finished in 1200s in total: > > grep elapsed ClipShapeTest.jtr > elapsed=1209067 0\:20\:09.067 > elapsed time (seconds): 1.131 > elapsed time (seconds): 1.129 > elapsed time (seconds): 70.291 > elapsed time (seconds): 0.0 > elapsed time (seconds): 244.185 > elapsed time (seconds): 0.0 > elapsed time (seconds): 127.729 > elapsed time (seconds): 0.0 > elapsed time (seconds): 187.525 > elapsed time (seconds): 0.0 > elapsed time (seconds): 60.818 > elapsed time (seconds): 0.0 > elapsed time (seconds): 200.825 > elapsed time (seconds): 0.0 > elapsed time (seconds): 126.312 > elapsed time (seconds): 0.0 > elapsed time (seconds): 190.248 > > > Regards, > Laurent -- Best regards, Sergey. From bourges.laurent at gmail.com Wed Apr 4 07:35:19 2018 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 04 Apr 2018 07:35:19 +0000 Subject: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out In-Reply-To: <55f4bed7-c603-5186-91c0-9214cec56430@oracle.com> References: <55f4bed7-c603-5186-91c0-9214cec56430@oracle.com> Message-ID: Do I need another approval ? Or it is enough to push this test only fix. Laurent Le mar. 3 avr. 2018 ? 23:26, Sergey Bylokhov a ?crit : > Looks fine. > > On 30/03/2018 13:09, Laurent Bourg?s wrote: > > Phil, > > Here is the ClipShapeTest change to fix timeout issue > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200526 > > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8200526.0/ > > > > I increased the timeout to 300s per test. > > > > I did a jtreg run on my machine (slowed down to 2Ghz) and it passed > > successfully although the ClipShapeTest finished in 1200s in total: > > > > grep elapsed ClipShapeTest.jtr > > elapsed=1209067 0\:20\:09.067 > > elapsed time (seconds): 1.131 > > elapsed time (seconds): 1.129 > > elapsed time (seconds): 70.291 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 244.185 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 127.729 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 187.525 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 60.818 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 200.825 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 126.312 > > elapsed time (seconds): 0.0 > > elapsed time (seconds): 190.248 > > > > > > Regards, > > Laurent > > > -- > Best regards, Sergey. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Apr 4 10:27:04 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 4 Apr 2018 03:27:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out In-Reply-To: References: <55f4bed7-c603-5186-91c0-9214cec56430@oracle.com> Message-ID: <1bfbcb54-8772-4faa-97e3-d4340646c742@default> Hi Laurent, ? I ran the updated test case in my Windows 7 machine and it passes without any time out. +1. ? Please update copyright year content to ?2017, 2018? before pushing, no need for another webrev. ? Thanks, Jay ? From: Laurent Bourg?s [mailto:bourges.laurent at gmail.com] Sent: Wednesday, April 04, 2018 1:05 PM To: Sergey Bylokhov Cc: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out ? Do I need another approval ? ? Or it is enough to push this test only fix. ? Laurent ? Le mar. 3 avr. 2018 ? 23:26, Sergey Bylokhov a ?crit?: Looks fine. On 30/03/2018 13:09, Laurent Bourg?s wrote: > Phil, > Here is the ClipShapeTest change to fix timeout issue > > JBS: https://bugs.openjdk.java.net/browse/JDK-8200526 > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8200526.0/ > > I increased the timeout to 300s per test. > > I did a jtreg run on my machine (slowed down to 2Ghz) and it passed > successfully although the ClipShapeTest finished in 1200s in total: > > grep elapsed ClipShapeTest.jtr > elapsed=1209067 0\:20\:09.067 > elapsed time (seconds): 1.131 > elapsed time (seconds): 1.129 > elapsed time (seconds): 70.291 > elapsed time (seconds): 0.0 > elapsed time (seconds): 244.185 > elapsed time (seconds): 0.0 > elapsed time (seconds): 127.729 > elapsed time (seconds): 0.0 > elapsed time (seconds): 187.525 > elapsed time (seconds): 0.0 > elapsed time (seconds): 60.818 > elapsed time (seconds): 0.0 > elapsed time (seconds): 200.825 > elapsed time (seconds): 0.0 > elapsed time (seconds): 126.312 > elapsed time (seconds): 0.0 > elapsed time (seconds): 190.248 > > > Regards, > Laurent -- Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 4 13:13:14 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 4 Apr 2018 06:13:14 -0700 Subject: [OpenJDK 2D-Dev] [11] JDK-8200526 Test sun/java2d/marlin/ClipShapeTest.java times out In-Reply-To: References: <55f4bed7-c603-5186-91c0-9214cec56430@oracle.com> Message-ID: <93B6EFF5-42E1-4106-A1A7-F3FE2423328D@oracle.com> +1 from me. -Phil. > On Apr 4, 2018, at 12:35 AM, Laurent Bourg?s wrote: > > Do I need another approval ? > > Or it is enough to push this test only fix. > > Laurent > >> Le mar. 3 avr. 2018 ? 23:26, Sergey Bylokhov a ?crit : >> Looks fine. >> >> On 30/03/2018 13:09, Laurent Bourg?s wrote: >> > Phil, >> > Here is the ClipShapeTest change to fix timeout issue >> > >> > JBS: https://bugs.openjdk.java.net/browse/JDK-8200526 >> > webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-8200526.0/ >> > >> > I increased the timeout to 300s per test. >> > >> > I did a jtreg run on my machine (slowed down to 2Ghz) and it passed >> > successfully although the ClipShapeTest finished in 1200s in total: >> > >> > grep elapsed ClipShapeTest.jtr >> > elapsed=1209067 0\:20\:09.067 >> > elapsed time (seconds): 1.131 >> > elapsed time (seconds): 1.129 >> > elapsed time (seconds): 70.291 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 244.185 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 127.729 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 187.525 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 60.818 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 200.825 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 126.312 >> > elapsed time (seconds): 0.0 >> > elapsed time (seconds): 190.248 >> > >> > >> > Regards, >> > Laurent >> >> >> -- >> Best regards, Sergey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Wed Apr 4 18:30:08 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Apr 2018 11:30:08 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196724: Change macosx deployment target to 10.9 Message-ID: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle. The switch has been tested for both Hotspot and client. The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team. Bug: https://bugs.openjdk.java.net/browse/JDK-8196724 Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html /Erik From tim.bell at oracle.com Wed Apr 4 19:36:53 2018 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 04 Apr 2018 12:36:53 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196724: Change macosx deployment target to 10.9 In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> Message-ID: <5AC52955.1000306@oracle.com> Erik: > This patch changes the values for the macosx version min and max > settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to > libc++ (explicitly for Hotspot and implicitly everywhere else). This > change is necessary to keep up with newer toolchain versions on Macosx > where using the old and no longer maintained libstdc++ has been > deprecated. This is done in preparation for bumping the preferred Xcode > version used for builds at Oracle. > > The switch has been tested for both Hotspot and client. > > The switch triggered some new deprecation warnings which have been > silenced and followup bugs have been filed on the concerned team. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196724 > > Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html Looks good. /Tim From erik.joelsson at oracle.com Wed Apr 4 20:27:54 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Apr 2018 13:27:54 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196724: Change macosx deployment target to 10.9 In-Reply-To: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com> References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com> Message-ID: On 2018-04-04 13:11, Gerard Ziemski wrote: > hi Erik, > > Thanks for doing this. > > I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs. > > Just a quick verification question (not very familiar with the makefiles), in line like this: > > DISABLED_WARNINGS_clang := deprecated-declarations > > I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler? Yes, (to be more precise -Wno-deprecated-declarations) this is the preferred way of disabling warnings in the build. /Erik > > cheers > >> On Apr 4, 2018, at 1:30 PM, Erik Joelsson wrote: >> >> This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle. >> >> The switch has been tested for both Hotspot and client. >> >> The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8196724 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html >> >> /Erik >> From gerard.ziemski at oracle.com Wed Apr 4 20:11:12 2018 From: gerard.ziemski at oracle.com (Gerard Ziemski) Date: Wed, 4 Apr 2018 15:11:12 -0500 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196724: Change macosx deployment target to 10.9 In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> Message-ID: <8763A5C5-FCD4-43A2-9DA9-B52FE240558B@oracle.com> hi Erik, Thanks for doing this. I like how you are using a narrow mechanism to turn off only those warnings that come up due to deprecated APIs. Just a quick verification question (not very familiar with the makefiles), in line like this: DISABLED_WARNINGS_clang := deprecated-declarations I assume we turn "deprecated-declarations? into ?-Wdeprecated-declarations? flag that then gets passed to the compiler? cheers > On Apr 4, 2018, at 1:30 PM, Erik Joelsson wrote: > > This patch changes the values for the macosx version min and max settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to libc++ (explicitly for Hotspot and implicitly everywhere else). This change is necessary to keep up with newer toolchain versions on Macosx where using the old and no longer maintained libstdc++ has been deprecated. This is done in preparation for bumping the preferred Xcode version used for builds at Oracle. > > The switch has been tested for both Hotspot and client. > > The switch triggered some new deprecation warnings which have been silenced and followup bugs have been filed on the concerned team. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196724 > > Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html > > /Erik > From erik.joelsson at oracle.com Thu Apr 5 00:01:31 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 4 Apr 2018 17:01:31 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8200793: Fix new compilation errors with Xcode 9.2 and deployment target 10.9 Message-ID: <4246e138-eb10-2b8e-8118-20ce2a0df2de@oracle.com> After bumping the deployment target to 10.9, a few more compilation errors were triggered with Xcode 9.2 in deploy and libt2k. Deploy fix looked trivial, but will soon be void anyway. In libt2k I simply disabled the warning as the source looks like something from upstream. Phil, do you think you will want to address this in a separate bug? Bug: https://bugs.openjdk.java.net/browse/JDK-8200793 Webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8200793/webrev.01/ /Erik From Sergey.Bylokhov at oracle.com Thu Apr 5 00:33:54 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 4 Apr 2018 17:33:54 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8196724: Change macosx deployment target to 10.9 In-Reply-To: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> References: <8d72eb36-4d81-908e-d3aa-ac8ff178feb0@oracle.com> Message-ID: <5fa6cb00-7070-cd2a-c5d9-ad256b17c5f9@oracle.com> Looks fine. On 04/04/2018 11:30, Erik Joelsson wrote: > This patch changes the values for the macosx version min and max > settings from 10.7 to 10.9. It also changes the stdlib from libstdc++ to > libc++ (explicitly for Hotspot and implicitly everywhere else). This > change is necessary to keep up with newer toolchain versions on Macosx > where using the old and no longer maintained libstdc++ has been > deprecated. This is done in preparation for bumping the preferred Xcode > version used for builds at Oracle. > > The switch has been tested for both Hotspot and client. > > The switch triggered some new deprecation warnings which have been > silenced and followup bugs have been filed on the concerned team. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8196724 > > Webrev: http://cr.openjdk.java.net/~erikj/8196724/webrev.01/index.html > > /Erik > -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Thu Apr 5 08:25:05 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 5 Apr 2018 10:25:05 +0200 Subject: [OpenJDK 2D-Dev] RFR: JDK-8200793: Fix new compilation errors with Xcode 9.2 and deployment target 10.9 In-Reply-To: <4246e138-eb10-2b8e-8118-20ce2a0df2de@oracle.com> References: <4246e138-eb10-2b8e-8118-20ce2a0df2de@oracle.com> Message-ID: <36ec62f6-ba50-2558-4c4f-80eb74fed5eb@oracle.com> On 2018-04-05 02:01, Erik Joelsson wrote: > After bumping the deployment target to 10.9, a few more compilation > errors were triggered with Xcode 9.2 in deploy and libt2k. > > Deploy fix looked trivial, but will soon be void anyway. In libt2k I > simply disabled the warning as the source looks like something from > upstream. Phil, do you think you will want to address this in a > separate bug? AFAIK, t2k is going away too, to be replaced by freetype. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8200793 > > Webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8200793/webrev.01/ Looks good to me. /Magnus > > /Erik > From jayathirth.d.v at oracle.com Thu Apr 5 09:56:02 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 5 Apr 2018 02:56:02 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> Message-ID: <4f048f06-8796-49e6-b127-87fa64d03e51@default> Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From prahalad.kumar.narayanan at oracle.com Fri Apr 6 08:11:54 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Fri, 6 Apr 2018 01:11:54 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <4f048f06-8796-49e6-b127-87fa64d03e51@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> Message-ID: <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> Hello Jay Good day to you. I looked into the latest changes. The code changes are nearly complete. Just a few tweaks. File: PNGImageReader.java Line: 1280 Rephrase from: /* * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY * if we have transparent pixel information from tRNS chunk * we need to consider that also and store proper information * in alpha channel. * * Also we create destination image with extra alpha channel * in getImageTypes() when we have tRNS chunk for colorType * PNG_COLOR_RGB or PNG_COLOR_GRAY. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY * that contain a specific transparent color (given by tRNS * chunk), we compare the decoded pixel color with the color * given by tRNS chunk to set the alpha on the destination. */ File: PNGImageReader.java Line: 1588 Rephrase from: /* * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we * have transparent pixel information in tRNS chunk * we create destination image having alpha channel. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that * contain a specific transparent color (given by tRNS chunk), we add * ImageTypeSpecifier(s) that support transparency to the list of * supported image types. */ File: PNGImageReader.java Line(s): 1290, 1493, 1596, 1619 . The lines mentioned above check whether metadata has specific transparent color using- metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY) . The above check is not only redundant but also metadata specific. . We could move the code to a common method in PNGMetadata- boolean hasTransparentColor() { return tRNS_present && (tRNS_colorType == PNG_COLOR_RGB || tRNS_colorType == PNG_COLOR_GRAY); } . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. . As per the specification, tRNS values depend on the image's color type. . This will reduce the complex check from- if (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1 && metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY)) { to- if (metadata.hasTransparentColor() && (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1)) { File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. File: PNGImageReader.java All modified Lines: . The opening braces '{' can appear in the new line. Some engineers do follow this. . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. Test File: ReadPngGrayImageWithTRNSChunk.java and ReadPngRGBImageWithTRNSChunk.java . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. . The call to directory(while is a File).delete() is not required in my view. Verify this once. . Dispose the writer after the write operation is complete. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, April 05, 2018 3:26 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From jayathirth.d.v at oracle.com Fri Apr 6 11:49:14 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 6 Apr 2018 11:49:14 +0000 (UTC) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> Message-ID: <96453525-66f2-4267-b3e3-bdde6cb3b864@default> Hi Prahalad, Thanks for your inputs. Regarding : File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: int[] temp = new int[inputBands + 1]; temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if (metadata.tRNS_colorType == PNG_COLOR_RGB) { I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. All other changes are updated. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, April 06, 2018 1:42 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest changes. The code changes are nearly complete. Just a few tweaks. File: PNGImageReader.java Line: 1280 Rephrase from: /* * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY * if we have transparent pixel information from tRNS chunk * we need to consider that also and store proper information * in alpha channel. * * Also we create destination image with extra alpha channel * in getImageTypes() when we have tRNS chunk for colorType * PNG_COLOR_RGB or PNG_COLOR_GRAY. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY * that contain a specific transparent color (given by tRNS * chunk), we compare the decoded pixel color with the color * given by tRNS chunk to set the alpha on the destination. */ File: PNGImageReader.java Line: 1588 Rephrase from: /* * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we * have transparent pixel information in tRNS chunk * we create destination image having alpha channel. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that * contain a specific transparent color (given by tRNS chunk), we add * ImageTypeSpecifier(s) that support transparency to the list of * supported image types. */ File: PNGImageReader.java Line(s): 1290, 1493, 1596, 1619 . The lines mentioned above check whether metadata has specific transparent color using- metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY) . The above check is not only redundant but also metadata specific. . We could move the code to a common method in PNGMetadata- boolean hasTransparentColor() { return tRNS_present && (tRNS_colorType == PNG_COLOR_RGB || tRNS_colorType == PNG_COLOR_GRAY); } . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. . As per the specification, tRNS values depend on the image's color type. . This will reduce the complex check from- if (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1 && metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY)) { to- if (metadata.hasTransparentColor() && (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1)) { File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. File: PNGImageReader.java All modified Lines: . The opening braces '{' can appear in the new line. Some engineers do follow this. . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. Test File: ReadPngGrayImageWithTRNSChunk.java and ReadPngRGBImageWithTRNSChunk.java . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. . The call to directory(while is a File).delete() is not required in my view. Verify this once. . Dispose the writer after the write operation is complete. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, April 05, 2018 3:26 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From TOSHIONA at jp.ibm.com Mon Apr 9 06:46:22 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Mon, 9 Apr 2018 15:46:22 +0900 Subject: [OpenJDK 2D-Dev] Proposal: Unicode Variation Selector Message-ID: Hello IBM would like to propose Unicode Variation Selector[1] capability to AWT and Swing components. (This proposal was posted to i18n-dev first, and I got a suggestion to discuss ?in 2d-dev.) This proposal changed the following files: src/java.desktop/share/classes/sun/font/CMap.java src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java src/java.desktop/share/classes/sun/font/Font2D.java src/java.desktop/share/classes/sun/font/FontRunIterator.java src/java.desktop/share/classes/sun/font/FontUtilities.java src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java src/java.desktop/share/native/common/font/sunfontids.h src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc src/java.desktop/share/native/libfontmanager/sunFont.c src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java 542 lines will be changed. There are three parts. 1) Adding CMap format 14 support 2) Adding CharsToGlyphs functions support Variation Selector Sequences 3) Swing text component's DEL and BS key operations change How would I go about obtaining a sponsor? [1] http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf ???? Chapter 23.4 Variation Selectors Best regards, Toshio Nakamura IBM Japan -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Mon Apr 9 08:53:06 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 9 Apr 2018 01:53:06 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <96453525-66f2-4267-b3e3-bdde6cb3b864@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> Message-ID: <94cbe6b3-0459-4542-8f66-4b00a0905740@default> Hello Jay I looked into the latest code changes. The code changes are good. Few minor corrections to PNGImageReader- . Line: 1310 . This missed my eye in the last review. . We could create int[] temp outside the for loop. I tried this with your changes & it works. . It's an optimization so that we don't end up creating int[] array for every pixel in the row. . Line: 1320, 1329 . Align the opening { on the same line as the if statement. . Line: 1479 . Correct the indentation of the expression within if condition. . A suggestion that could help: if ((theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1) && metadata.hasTransparentColor()) { // code block checkReadParamBandSettings(param, ... } Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Friday, April 06, 2018 5:19 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Prahalad, Thanks for your inputs. Regarding : File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: int[] temp = new int[inputBands + 1]; temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if (metadata.tRNS_colorType == PNG_COLOR_RGB) { I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. All other changes are updated. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, April 06, 2018 1:42 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest changes. The code changes are nearly complete. Just a few tweaks. File: PNGImageReader.java Line: 1280 Rephrase from: /* * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY * if we have transparent pixel information from tRNS chunk * we need to consider that also and store proper information * in alpha channel. * * Also we create destination image with extra alpha channel * in getImageTypes() when we have tRNS chunk for colorType * PNG_COLOR_RGB or PNG_COLOR_GRAY. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY * that contain a specific transparent color (given by tRNS * chunk), we compare the decoded pixel color with the color * given by tRNS chunk to set the alpha on the destination. */ File: PNGImageReader.java Line: 1588 Rephrase from: /* * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we * have transparent pixel information in tRNS chunk * we create destination image having alpha channel. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that * contain a specific transparent color (given by tRNS chunk), we add * ImageTypeSpecifier(s) that support transparency to the list of * supported image types. */ File: PNGImageReader.java Line(s): 1290, 1493, 1596, 1619 . The lines mentioned above check whether metadata has specific transparent color using- metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY) . The above check is not only redundant but also metadata specific. . We could move the code to a common method in PNGMetadata- boolean hasTransparentColor() { return tRNS_present && (tRNS_colorType == PNG_COLOR_RGB || tRNS_colorType == PNG_COLOR_GRAY); } . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. . As per the specification, tRNS values depend on the image's color type. . This will reduce the complex check from- if (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1 && metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY)) { to- if (metadata.hasTransparentColor() && (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1)) { File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. File: PNGImageReader.java All modified Lines: . The opening braces '{' can appear in the new line. Some engineers do follow this. . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. Test File: ReadPngGrayImageWithTRNSChunk.java and ReadPngRGBImageWithTRNSChunk.java . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. . The call to directory(while is a File).delete() is not required in my view. Verify this once. . Dispose the writer after the write operation is complete. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, April 05, 2018 3:26 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From jayathirth.d.v at oracle.com Tue Apr 10 06:19:19 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 9 Apr 2018 23:19:19 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <94cbe6b3-0459-4542-8f66-4b00a0905740@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> <94cbe6b3-0459-4542-8f66-4b00a0905740@default> Message-ID: HI Prahalad, Thanks for your inputs. Regarding- Few minor corrections to PNGImageReader- . Line: 1310 . This missed my eye in the last review. . We could create int[] temp outside the for loop. I tried this with your changes & it works. . It's an optimization so that we don't end up creating int[] array for every pixel in the row. Before sending webrev.06, I actually made similar changes of moving temp[] creation and/or calculating "opaque" to outside of for loop. But this will cause creation of temp[] and/ or calculation of "opaque" for each row in all the cases where there is no RGB/Gray & tRNS combination. So I reverted those change before sending webrev.06. I would like to keep all the calculation specific to RGB/Gray & tRNS combination in its own code flow. Other modifications are made. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.07/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 09, 2018 2:23 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay I looked into the latest code changes. The code changes are good. Few minor corrections to PNGImageReader- . Line: 1310 . This missed my eye in the last review. . We could create int[] temp outside the for loop. I tried this with your changes & it works. . It's an optimization so that we don't end up creating int[] array for every pixel in the row. . Line: 1320, 1329 . Align the opening { on the same line as the if statement. . Line: 1479 . Correct the indentation of the expression within if condition. . A suggestion that could help: if ((theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1) && metadata.hasTransparentColor()) { // code block checkReadParamBandSettings(param, ... } Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Friday, April 06, 2018 5:19 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Prahalad, Thanks for your inputs. Regarding : File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: int[] temp = new int[inputBands + 1]; temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if (metadata.tRNS_colorType == PNG_COLOR_RGB) { I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. All other changes are updated. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, April 06, 2018 1:42 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest changes. The code changes are nearly complete. Just a few tweaks. File: PNGImageReader.java Line: 1280 Rephrase from: /* * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY * if we have transparent pixel information from tRNS chunk * we need to consider that also and store proper information * in alpha channel. * * Also we create destination image with extra alpha channel * in getImageTypes() when we have tRNS chunk for colorType * PNG_COLOR_RGB or PNG_COLOR_GRAY. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY * that contain a specific transparent color (given by tRNS * chunk), we compare the decoded pixel color with the color * given by tRNS chunk to set the alpha on the destination. */ File: PNGImageReader.java Line: 1588 Rephrase from: /* * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we * have transparent pixel information in tRNS chunk * we create destination image having alpha channel. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that * contain a specific transparent color (given by tRNS chunk), we add * ImageTypeSpecifier(s) that support transparency to the list of * supported image types. */ File: PNGImageReader.java Line(s): 1290, 1493, 1596, 1619 . The lines mentioned above check whether metadata has specific transparent color using- metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY) . The above check is not only redundant but also metadata specific. . We could move the code to a common method in PNGMetadata- boolean hasTransparentColor() { return tRNS_present && (tRNS_colorType == PNG_COLOR_RGB || tRNS_colorType == PNG_COLOR_GRAY); } . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. . As per the specification, tRNS values depend on the image's color type. . This will reduce the complex check from- if (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1 && metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY)) { to- if (metadata.hasTransparentColor() && (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1)) { File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. File: PNGImageReader.java All modified Lines: . The opening braces '{' can appear in the new line. Some engineers do follow this. . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. Test File: ReadPngGrayImageWithTRNSChunk.java and ReadPngRGBImageWithTRNSChunk.java . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. . The call to directory(while is a File).delete() is not required in my view. Verify this once. . Dispose the writer after the write operation is complete. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, April 05, 2018 3:26 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From prahalad.kumar.narayanan at oracle.com Tue Apr 10 06:40:49 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 9 Apr 2018 23:40:49 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> <94cbe6b3-0459-4542-8f66-4b00a0905740@default> Message-ID: Hello Jay Changes look good. Thanks Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Tuesday, April 10, 2018 11:49 AM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images HI Prahalad, Thanks for your inputs. Regarding- Few minor corrections to PNGImageReader- . Line: 1310 . This missed my eye in the last review. . We could create int[] temp outside the for loop. I tried this with your changes & it works. . It's an optimization so that we don't end up creating int[] array for every pixel in the row. Before sending webrev.06, I actually made similar changes of moving temp[] creation and/or calculating "opaque" to outside of for loop. But this will cause creation of temp[] and/ or calculation of "opaque" for each row in all the cases where there is no RGB/Gray & tRNS combination. So I reverted those change before sending webrev.06. I would like to keep all the calculation specific to RGB/Gray & tRNS combination in its own code flow. Other modifications are made. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.07/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 09, 2018 2:23 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay I looked into the latest code changes. The code changes are good. Few minor corrections to PNGImageReader- . Line: 1310 . This missed my eye in the last review. . We could create int[] temp outside the for loop. I tried this with your changes & it works. . It's an optimization so that we don't end up creating int[] array for every pixel in the row. . Line: 1320, 1329 . Align the opening { on the same line as the if statement. . Line: 1479 . Correct the indentation of the expression within if condition. . A suggestion that could help: if ((theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1) && metadata.hasTransparentColor()) { // code block checkReadParamBandSettings(param, ... } Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Friday, April 06, 2018 5:19 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Prahalad, Thanks for your inputs. Regarding : File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: int[] temp = new int[inputBands + 1]; temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if (metadata.tRNS_colorType == PNG_COLOR_RGB) { I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. All other changes are updated. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Friday, April 06, 2018 1:42 PM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest changes. The code changes are nearly complete. Just a few tweaks. File: PNGImageReader.java Line: 1280 Rephrase from: /* * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY * if we have transparent pixel information from tRNS chunk * we need to consider that also and store proper information * in alpha channel. * * Also we create destination image with extra alpha channel * in getImageTypes() when we have tRNS chunk for colorType * PNG_COLOR_RGB or PNG_COLOR_GRAY. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY * that contain a specific transparent color (given by tRNS * chunk), we compare the decoded pixel color with the color * given by tRNS chunk to set the alpha on the destination. */ File: PNGImageReader.java Line: 1588 Rephrase from: /* * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we * have transparent pixel information in tRNS chunk * we create destination image having alpha channel. */ Rephrase to: /* * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that * contain a specific transparent color (given by tRNS chunk), we add * ImageTypeSpecifier(s) that support transparency to the list of * supported image types. */ File: PNGImageReader.java Line(s): 1290, 1493, 1596, 1619 . The lines mentioned above check whether metadata has specific transparent color using- metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY) . The above check is not only redundant but also metadata specific. . We could move the code to a common method in PNGMetadata- boolean hasTransparentColor() { return tRNS_present && (tRNS_colorType == PNG_COLOR_RGB || tRNS_colorType == PNG_COLOR_GRAY); } . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. . As per the specification, tRNS values depend on the image's color type. . This will reduce the complex check from- if (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1 && metadata.tRNS_present && (metadata.tRNS_colorType == PNG_COLOR_RGB || metadata.tRNS_colorType == PNG_COLOR_GRAY)) { to- if (metadata.hasTransparentColor() && (theImage.getSampleModel().getNumBands() == inputBandsForColorType[colorType] + 1)) { File: PNGImageReader.java Line: 1329, 1342 . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. int[] temp = new int[inputBands + 1]; int opaque = (bitDepth < 16) ? 255 : 65535; Arrays.fill(temp, opaque); . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. File: PNGImageReader.java All modified Lines: . The opening braces '{' can appear in the new line. Some engineers do follow this. . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. Test File: ReadPngGrayImageWithTRNSChunk.java and ReadPngRGBImageWithTRNSChunk.java . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. . The call to directory(while is a File).delete() is not required in my view. Verify this once. . Dispose the writer after the write operation is complete. Thank you Have a good day Prahalad N. -----Original Message----- From: Jayathirth D V Sent: Thursday, April 05, 2018 3:26 PM To: Prahalad Kumar Narayanan; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Prahalad, Thank you for the inputs. I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). isTransparentPixelPresent() code is removed and we are using available tRNS properties. I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ Thanks, Jay -----Original Message----- From: Prahalad Kumar Narayanan Sent: Monday, April 02, 2018 12:03 PM To: Krishna Addepalli; Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello Jay Good day to you. I looked into the latest code changes. Please find my review observation & suggestions herewith. My understanding of problem statement: . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. Appropriate Changes: File: PNGImageReader.java, Method: Iterator getImageTypes Line: 1633 . This method is internally invoked while creating BufferedImage for destination at Line 1409: theImage = getDestination(param, getImageTypes(0), width, height); . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. File: PNGImageReader.java Method: readMetadata Line: 731 . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. . The chunk's information will be needed. Other Observation & Suggestions: File: PNGImageReader.java, Method: decodePass Line: (1088 - 1112), (1277-1327) . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. . The changes are not required in my view. Reasons are- . passRow corresponds to the data from input image source. . imgRas corresponds to the destination buffered image. . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. . However, the proposed changes modify how we interpret the source through passRow. . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. File: PNGImageReader.java, Method: isTransparentPixelPresent Line: 1545 . The logic of this method considers both input image source and destination bands to decide whether transparency is available. . In my view, The method should consider only the alpha in input image source and not the destination. . Here are code points where the method is invoked a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. . Each of the locations except (c) pertain to image source and not the destination. . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" . Just curious to know if there 's any basis for this observation ? . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. Line: 1555 . Please use tRNS_colorType together with tRNS_present flag. File: PNGImageReader.java, Method: readMetadata Line: 701 Rephrase From: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. But we need * to parse only the tRNS chunk even in the case where IHDR colortype * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent * pixel information for PNG_COLOR_RGB while storing the pixel data * in decodePass(). To: * Optimization: We can skip reading metadata if ignoreMetadata * flag is set and colorType is not PNG_COLOR_PALETTE. However, * we parse tRNS chunk to retrieve the transparent color from the * metadata irrespective of the colorType. Doing so, helps * PNGImageReader to appropriately identify and set transparent * pixels in the decoded image. File: PNGMetadata.java Line: 271 . Reset the tRNS_colorType to -1 in the reset() method. . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. . When the same ImageReader is used to read multiple PNG images, this could pose a problem. Thank you Have a good day Prahalad N. ----- Original Message ----- From: Krishna Addepalli Sent: Monday, April 02, 2018 11:40 AM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. Thanks, Krishna From: Jayathirth D V Sent: Monday, April 2, 2018 11:33 AM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, The constant values for different color types is : ??? static final int PNG_COLOR_GRAY = 0; ??? static final int PNG_COLOR_RGB = 2; ??? static final int PNG_COLOR_PALETTE = 3; ??? static final int PNG_COLOR_GRAY_ALPHA = 4; ??? static final int PNG_COLOR_RGB_ALPHA = 6; Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. Thanks, Jay From: Krishna Addepalli Sent: Monday, April 02, 2018 9:56 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 1:43 PM To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Krishna, Thanks for providing the inputs. 1. I suggest to rename considerTransparentPixel as isAlphaPresent. As discussed I have added new name as isTransparentPixelPresent() 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); ???????????? ???Changes are made. 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow ?will be used ?for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. Changes are made. Please find updated webrev for review : http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ Thanks, Jay From: Krishna Addepalli Sent: Wednesday, March 28, 2018 11:52 AM To: Jayathirth D V; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hi Jay, I have some points as below: 1. I suggest to rename considerTransparentPixel as isAlphaPresent. 2. You can refactor the function body as below: ????? Return ((destinationBands == null || ??????????? destinationBands.length == 4) && ???????????? metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: for (int i = 0; i < passWidth; i++) { ???????????????????????????? byteData[destidx] = curr[srcidx]; ???????????????????????????? byteData[destidx + 1] = curr[srcidx + 1]; ???????????????????????????? byteData[destidx + 2] = curr[srcidx + 2]; ??????????????????????? if (curr[srcidx] == (byte)metadata.tRNS_red && ???????????????????????????? curr[srcidx + 1] == (byte)metadata.tRNS_green && ???????????????????????????? curr[srcidx + 2] == (byte)metadata.tRNS_blue) ???????????????????????? { ???????????????????????????? byteData[destidx + 3] = (byte)0; ??????????????????????? } else { ????????????????????????????byteData[destidx + 3] = (byte)255; ???????????????????????? } ???????????????????????? srcidx += 3; ???????????????????????? destidx += 4; ???????????????????? } Same thing can be done for the loop that executes for 16bit pixel data. I haven't yet checked the test cases. Thanks, Krishna From: Jayathirth D V Sent: Wednesday, March 28, 2018 9:52 AM To: 2d-dev <2d-dev at openjdk.java.net> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ Thanks, Jay From: Jayathirth D V Sent: Wednesday, March 28, 2018 8:28 AM To: 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, March 27, 2018 6:51 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images Hello All, Please review the following solution in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. Root cause: ?In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. Thanks, Jay From jayathirth.d.v at oracle.com Wed Apr 11 10:51:18 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 11 Apr 2018 03:51:18 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Message-ID: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 Webrev : http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ Issue: PNGImageWriter. write_bKGD() function sets incorrect R, G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). Solution: Assign values to all channels of RGB as they are present in Metadata instead of using only bKGD red value. Note : Our default metadata doesn't set any bKGD chunk but if user specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B values and if r == g == b then we store bKGD chunk as of type PNG_COLOR_GRAY. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Wed Apr 11 14:05:08 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Wed, 11 Apr 2018 15:05:08 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData Message-ID: Hi, Please review the fix for jdk11: bug: https://bugs.openjdk.java.net/browse/JDK-8201240 webrev: http://cr.openjdk.java.net/~aivanov/8201240/jdk11/webrev.00/ BufImgSurfaceData.ICMColorData uses finalize() to dispose of native resources. 2D components usually use Java 2D Disposer. It can be used here too, and the now deprecated finalize() can be removed consequently. I ran SwingSet2 and Java2Demo. When BufImgSurfaceData.ICMColorData objects become unreachable, BufImg_Dispose_ICMColorData gets called and the associated native resources are freed. Thank you in advance. Regards, Alexey From philip.race at oracle.com Wed Apr 11 15:46:13 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 08:46:13 -0700 Subject: [OpenJDK 2D-Dev] Proposal: Unicode Variation Selector In-Reply-To: References: Message-ID: <79127e03-f9c3-5138-bf4e-60a911b3a9b0@oracle.com> I recommend you ask Steven Loomis to sponsor this - and probably the input method support, but particularly this one. -phil. On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > Hello > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > and Swing components. > (This proposal was posted to i18n-dev first, and I got a suggestion to > discuss > in 2d-dev.) > > This proposal changed the following files: > src/java.desktop/share/classes/sun/font/CMap.java > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > src/java.desktop/share/classes/sun/font/Font2D.java > src/java.desktop/share/classes/sun/font/FontRunIterator.java > src/java.desktop/share/classes/sun/font/FontUtilities.java > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > src/java.desktop/share/native/common/font/sunfontids.h > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > src/java.desktop/share/native/libfontmanager/sunFont.c > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > 542 lines will be changed. > > There are three parts. > 1) Adding CMap format 14 support > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > 3) Swing text component's DEL and BS key operations change > > > How would I go about obtaining a sponsor? > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > Chapter 23.4 Variation Selectors > > Best regards, > > Toshio Nakamura > IBM Japan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Apr 11 16:52:50 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 09:52:50 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> <94cbe6b3-0459-4542-8f66-4b00a0905740@default> Message-ID: http://cr.openjdk.java.net/~jdv/6788458/webrev.07/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java.udiff.html There's an extra line added at the end which you can remove. Why do the tests needs to create temp disk files ? Can't we do this all with ByteArrayInput/OutputStream ? Less worry about clean up there. I note that this 286 boolean tRNSTransparentPixelPresent = 1287 theImage.getSampleModel().getNumBands() == inputBands + 1 && 1288 metadata.hasTransparentColor(); is evaluated for each row when I expect it only needs to be evaluated once for the whole decode pass. But the overhed is presumably low and it is next to the use so I think it should be OK as is. However the code that does the transparent per-pixel settings does seem needlessly wasteful. These can be moved outside at least the entire row decode : final int[] temp = new int[inputBands + 1]; final int opaque = (bitDepth < 16) ? 255 : 65535; Note that I added final to them .. Also array accesses are (relatively) slow but since you need an array to pass to setPixel and there's only two accesses I don't see how we can improve on that here by assigning the values from the ps array to local variables. -phil. On 04/09/2018 11:19 PM, Jayathirth D V wrote: > HI Prahalad, > > Thanks for your inputs. > > Regarding- > Few minor corrections to PNGImageReader- . Line: 1310 > . This missed my eye in the last review. > . We could create int[] temp outside the for loop. I tried this with your changes & it works. > . It's an optimization so that we don't end up creating int[] array for every pixel in the row. > > Before sending webrev.06, I actually made similar changes of moving temp[] creation and/or calculating "opaque" to outside of for loop. > But this will cause creation of temp[] and/ or calculation of "opaque" for each row in all the cases where there is no RGB/Gray & tRNS combination. So I reverted those change before sending webrev.06. > I would like to keep all the calculation specific to RGB/Gray & tRNS combination in its own code flow. > > Other modifications are made. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.07/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Monday, April 09, 2018 2:23 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > I looked into the latest code changes. > The code changes are good. > > Few minor corrections to PNGImageReader- . Line: 1310 > . This missed my eye in the last review. > . We could create int[] temp outside the for loop. I tried this with your changes & it works. > . It's an optimization so that we don't end up creating int[] array for every pixel in the row. > > . Line: 1320, 1329 > . Align the opening { on the same line as the if statement. > > . Line: 1479 > . Correct the indentation of the expression within if condition. > . A suggestion that could help: > if ((theImage.getSampleModel().getNumBands() > == inputBandsForColorType[colorType] + 1) > && metadata.hasTransparentColor()) { > // code block > checkReadParamBandSettings(param, > ... > } > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Friday, April 06, 2018 5:19 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hi Prahalad, > > Thanks for your inputs. > > Regarding : > File: PNGImageReader.java > Line: 1329, 1342 > . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. > . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. > int[] temp = new int[inputBands + 1]; > int opaque = (bitDepth < 16) ? 255 : 65535; > Arrays.fill(temp, opaque); > . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. > > I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. > > Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: > int[] temp = new int[inputBands + 1]; > temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if (metadata.tRNS_colorType == PNG_COLOR_RGB) { > > I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. > So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. > > All other changes are updated. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, April 06, 2018 1:42 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > Good day to you. > > I looked into the latest changes. > The code changes are nearly complete. Just a few tweaks. > > File: PNGImageReader.java > Line: 1280 > Rephrase from: > /* > * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY > * if we have transparent pixel information from tRNS chunk > * we need to consider that also and store proper information > * in alpha channel. > * > * Also we create destination image with extra alpha channel > * in getImageTypes() when we have tRNS chunk for colorType > * PNG_COLOR_RGB or PNG_COLOR_GRAY. > */ > Rephrase to: > /* > * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY > * that contain a specific transparent color (given by tRNS > * chunk), we compare the decoded pixel color with the color > * given by tRNS chunk to set the alpha on the destination. > */ > > File: PNGImageReader.java > Line: 1588 > Rephrase from: > /* > * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we > * have transparent pixel information in tRNS chunk > * we create destination image having alpha channel. > */ > > Rephrase to: > /* > * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that > * contain a specific transparent color (given by tRNS chunk), we add > * ImageTypeSpecifier(s) that support transparency to the list of > * supported image types. > */ > > File: PNGImageReader.java > Line(s): 1290, 1493, 1596, 1619 > . The lines mentioned above check whether metadata has specific transparent color using- > metadata.tRNS_present && > (metadata.tRNS_colorType == PNG_COLOR_RGB || > metadata.tRNS_colorType == PNG_COLOR_GRAY) > > . The above check is not only redundant but also metadata specific. > . We could move the code to a common method in PNGMetadata- > boolean hasTransparentColor() { > return tRNS_present > && (tRNS_colorType == PNG_COLOR_RGB > || tRNS_colorType == PNG_COLOR_GRAY); > } > . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. > . As per the specification, tRNS values depend on the image's color type. > . This will reduce the complex check from- > if (theImage.getSampleModel().getNumBands() == > inputBandsForColorType[colorType] + 1 && > metadata.tRNS_present && > (metadata.tRNS_colorType == PNG_COLOR_RGB || > metadata.tRNS_colorType == PNG_COLOR_GRAY)) > { > to- > if (metadata.hasTransparentColor() > && (theImage.getSampleModel().getNumBands() == > inputBandsForColorType[colorType] + 1)) { > > File: PNGImageReader.java > Line: 1329, 1342 > . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. > . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. > int[] temp = new int[inputBands + 1]; > int opaque = (bitDepth < 16) ? 255 : 65535; > Arrays.fill(temp, opaque); > . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. > > File: PNGImageReader.java > All modified Lines: > . The opening braces '{' can appear in the new line. Some engineers do follow this. > . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. > > Test File: ReadPngGrayImageWithTRNSChunk.java and > ReadPngRGBImageWithTRNSChunk.java > . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. > . The call to directory(while is a File).delete() is not required in my view. Verify this once. > . Dispose the writer after the write operation is complete. > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, April 05, 2018 3:26 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello Prahalad, > > Thank you for the inputs. > > I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. > I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). > isTransparentPixelPresent() code is removed and we are using available tRNS properties. > > I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Monday, April 02, 2018 12:03 PM > To: Krishna Addepalli; Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > Good day to you. > > I looked into the latest code changes. > Please find my review observation & suggestions herewith. > > My understanding of problem statement: > . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. > . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. > > Appropriate Changes: > > File: PNGImageReader.java, > Method: Iterator getImageTypes > Line: 1633 > . This method is internally invoked while creating BufferedImage for destination at Line 1409: > theImage = getDestination(param, > getImageTypes(0), > width, > height); > . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. > > File: PNGImageReader.java > Method: readMetadata > Line: 731 > . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. > . The chunk's information will be needed. > > Other Observation & Suggestions: > > File: PNGImageReader.java, > Method: decodePass > Line: (1088 - 1112), (1277-1327) > . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. > . The changes are not required in my view. Reasons are- > . passRow corresponds to the data from input image source. > . imgRas corresponds to the destination buffered image. > . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. > imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. > . However, the proposed changes modify how we interpret the source through passRow. > . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. > . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. > > File: PNGImageReader.java, > Method: isTransparentPixelPresent > Line: 1545 > . The logic of this method considers both input image source and destination bands to decide whether transparency is available. > . In my view, The method should consider only the alpha in input image source and not the destination. > . Here are code points where the method is invoked > a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. > b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. > c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) > d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. > . Each of the locations except (c) pertain to image source and not the destination. > . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). > > . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. > . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" > . Just curious to know if there 's any basis for this observation ? > . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. > > Line: 1555 > . Please use tRNS_colorType together with tRNS_present flag. > > File: PNGImageReader.java, > Method: readMetadata > Line: 701 > Rephrase From: > * Optimization: We can skip reading metadata if ignoreMetadata > * flag is set and colorType is not PNG_COLOR_PALETTE. But we need > * to parse only the tRNS chunk even in the case where IHDR colortype > * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent > * pixel information for PNG_COLOR_RGB while storing the pixel data > * in decodePass(). > To: > * Optimization: We can skip reading metadata if ignoreMetadata > * flag is set and colorType is not PNG_COLOR_PALETTE. However, > * we parse tRNS chunk to retrieve the transparent color from the > * metadata irrespective of the colorType. Doing so, helps > * PNGImageReader to appropriately identify and set transparent > * pixels in the decoded image. > > File: PNGMetadata.java > Line: 271 > . Reset the tRNS_colorType to -1 in the reset() method. > . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. > . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. > . When the same ImageReader is used to read multiple PNG images, this could pose a problem. > > Thank you > Have a good day > > Prahalad N. > > > ----- Original Message ----- > From: Krishna Addepalli > Sent: Monday, April 02, 2018 11:40 AM > To: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. > Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. > > Thanks, > Krishna > > From: Jayathirth D V > Sent: Monday, April 2, 2018 11:33 AM > To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hi Krishna, > > The constant values for different color types is : > static final int PNG_COLOR_GRAY = 0; > static final int PNG_COLOR_RGB = 2; > static final int PNG_COLOR_PALETTE = 3; > static final int PNG_COLOR_GRAY_ALPHA = 4; > static final int PNG_COLOR_RGB_ALPHA = 6; > > Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. > By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. > > Thanks, > Jay > > From: Krishna Addepalli > Sent: Monday, April 02, 2018 9:56 AM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hi Jay, > > The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? > > Thanks, > Krishna > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 1:43 PM > To: Krishna Addepalli ; 2d-dev <2d-dev at openjdk.java.net> > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hi Krishna, > > Thanks for providing the inputs. > > 1. I suggest to rename considerTransparentPixel as isAlphaPresent. > As discussed I have added new name as isTransparentPixelPresent() > > 2. You can refactor the function body as below: > Return ((destinationBands == null || > destinationBands.length == 4) && > metadata.tRNS_colorType == PNG_COLOR_RGB); > > Changes are made. > > 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. > > Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. > Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. > > 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: > for (int i = 0; i < passWidth; i++) { > byteData[destidx] = curr[srcidx]; > byteData[destidx + 1] = curr[srcidx + 1]; > byteData[destidx + 2] = curr[srcidx + 2]; > if (curr[srcidx] == (byte)metadata.tRNS_red && > curr[srcidx + 1] == (byte)metadata.tRNS_green && > curr[srcidx + 2] == (byte)metadata.tRNS_blue) > { > byteData[destidx + 3] = (byte)0; > } else { > byteData[destidx + 3] = (byte)255; > } > srcidx += 3; > destidx += 4; > } > Same thing can be done for the loop that executes for 16bit pixel data. > > Changes are made. > > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ > > Thanks, > Jay > > From: Krishna Addepalli > Sent: Wednesday, March 28, 2018 11:52 AM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hi Jay, > > I have some points as below: > 1. I suggest to rename considerTransparentPixel as isAlphaPresent. > 2. You can refactor the function body as below: > Return ((destinationBands == null || > destinationBands.length == 4) && > metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. > 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: > for (int i = 0; i < passWidth; i++) { > byteData[destidx] = curr[srcidx]; > byteData[destidx + 1] = curr[srcidx + 1]; > byteData[destidx + 2] = curr[srcidx + 2]; > if (curr[srcidx] == (byte)metadata.tRNS_red && > curr[srcidx + 1] == (byte)metadata.tRNS_green && > curr[srcidx + 2] == (byte)metadata.tRNS_blue) > { > byteData[destidx + 3] = (byte)0; > } else { > byteData[destidx + 3] = (byte)255; > } > srcidx += 3; > destidx += 4; > } > Same thing can be done for the loop that executes for 16bit pixel data. > > > I haven't yet checked the test cases. > > Thanks, > Krishna > > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 9:52 AM > To: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello All, > > I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ > > Thanks, > Jay > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 8:28 AM > To: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello All, > > I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ > > Thanks, > Jay > > From: Jayathirth D V > Sent: Tuesday, March 27, 2018 6:51 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > Hello All, > > Please review the following solution in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 > Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ > > Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. > > Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. > > Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. > > Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. > > One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. > > Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. > > Thanks, > Jay From philip.race at oracle.com Wed Apr 11 16:59:19 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 09:59:19 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8200793: Fix new compilation errors with Xcode 9.2 and deployment target 10.9 In-Reply-To: <36ec62f6-ba50-2558-4c4f-80eb74fed5eb@oracle.com> References: <4246e138-eb10-2b8e-8118-20ce2a0df2de@oracle.com> <36ec62f6-ba50-2558-4c4f-80eb74fed5eb@oracle.com> Message-ID: <608a4394-2769-7209-804d-8823c3e3af06@oracle.com> Correct, I will be removing t2k soon so there is no need to address it in 11. Just disabling the warning will suffice. -phil. On 04/05/2018 01:25 AM, Magnus Ihse Bursie wrote: > > On 2018-04-05 02:01, Erik Joelsson wrote: >> After bumping the deployment target to 10.9, a few more compilation >> errors were triggered with Xcode 9.2 in deploy and libt2k. >> >> Deploy fix looked trivial, but will soon be void anyway. In libt2k I >> simply disabled the warning as the source looks like something from >> upstream. Phil, do you think you will want to address this in a >> separate bug? > AFAIK, t2k is going away too, to be replaced by freetype. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8200793 >> >> Webrev: http://javaweb.us.oracle.com/~ejoelsso/webrev/8200793/webrev.01/ > Looks good to me. > > /Magnus > >> >> /Erik >> > From philip.race at oracle.com Wed Apr 11 17:06:03 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 10:06:03 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData In-Reply-To: References: Message-ID: <1755815d-6a27-8f28-16f2-650e192c0f6a@oracle.com> +1 -phil. On 04/11/2018 07:05 AM, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk11: > > bug: https://bugs.openjdk.java.net/browse/JDK-8201240 > webrev: http://cr.openjdk.java.net/~aivanov/8201240/jdk11/webrev.00/ > > > BufImgSurfaceData.ICMColorData uses finalize() to dispose of native > resources. > > 2D components usually use Java 2D Disposer. It can be used here too, > and the now deprecated finalize() can be removed consequently. > > I ran SwingSet2 and Java2Demo. > When BufImgSurfaceData.ICMColorData objects become unreachable, > BufImg_Dispose_ICMColorData gets called and the associated native > resources are freed. > > > Thank you in advance. > > Regards, > Alexey From philip.race at oracle.com Wed Apr 11 17:10:25 2018 From: philip.race at oracle.com (Phil Race) Date: Wed, 11 Apr 2018 10:10:25 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: References: Message-ID: The fix seems fine but like the other review I wonder if the test can use a bytearrayoutputstream instead of writing to a file. -phil. On 04/11/2018 03:51 AM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 > > Webrev : http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ > > > _Issue:_ PNGImageWriter. write_bKGD() function sets incorrect R, G, B > value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). > > _Solution:_ Assign values to all channels of RGB as they are present > in Metadata instead of using only bKGD red value. > > _Note_ : Our default metadata doesn?t set any bKGD chunk but if user > specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B > values and if r == g == b then we store bKGD chunk as of type > PNG_COLOR_GRAY. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Wed Apr 11 22:04:09 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Apr 2018 15:04:09 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData In-Reply-To: References: Message-ID: <605c5260-7f19-5a91-935c-21be69d9cdc8@oracle.com> Looks fine. On 11/04/2018 07:05, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk11: > > bug: https://bugs.openjdk.java.net/browse/JDK-8201240 > webrev: http://cr.openjdk.java.net/~aivanov/8201240/jdk11/webrev.00/ > > > BufImgSurfaceData.ICMColorData uses finalize() to dispose of native > resources. > > 2D components usually use Java 2D Disposer. It can be used here too, and > the now deprecated finalize() can be removed consequently. > > I ran SwingSet2 and Java2Demo. > When BufImgSurfaceData.ICMColorData objects become unreachable, > BufImg_Dispose_ICMColorData gets called and the associated native > resources are freed. > > > Thank you in advance. > > Regards, > Alexey -- Best regards, Sergey. From alexey.ivanov at oracle.com Thu Apr 12 15:25:18 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 16:25:18 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM Message-ID: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> Hi, Please review the fix for jdk11: bug: https://bugs.openjdk.java.net/browse/JDK-8201433 webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.00/ When the JVM is run with limited amount of memory, initCubemap function called from BufImg_SetupICM can return NULL. It can lead to a crash. It usually happens when native memory is exhausted and malloc fails. In this state, JVM itself is not stable. Adding NULL-check can prevent the crash in this particular place. However, if the app continues, since native memory is exhausted and malloc fails, JVM can still crash in another place. Thank you in advance. Regards, Alexey From philip.race at oracle.com Thu Apr 12 17:01:51 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Apr 2018 10:01:51 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM In-Reply-To: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> References: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> Message-ID: <36b75ef6-dc51-d2b0-fa48-cd72c4318a46@oracle.com> +1 -phil. On 04/12/2018 08:25 AM, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk11: > > bug: https://bugs.openjdk.java.net/browse/JDK-8201433 > webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.00/ > > > When the JVM is run with limited amount of memory, initCubemap > function called from BufImg_SetupICM can return NULL. It can lead to a > crash. It usually happens when native memory is exhausted and malloc > fails. In this state, JVM itself is not stable. > > Adding NULL-check can prevent the crash in this particular place. > However, if the app continues, since native memory is exhausted and > malloc fails, JVM can still crash in another place. > > > Thank you in advance. > > Regards, > Alexey From philip.race at oracle.com Thu Apr 12 18:38:04 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Apr 2018 11:38:04 -0700 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> Message-ID: <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com> I was just directed to this look at this change. I don't know why it is being reviewed exclusively on build-dev since no build files are being changed. 50% of it should have been sent to 2d-dev and the rest on core-libs + hotspot .. Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? -phil. On 04/12/2018 12:49 AM, Baesken, Matthias wrote: > Hi, could someone please sponsor the change now ? > > And could someone please check what happened to the submit-repo ? > Yesterday I pushed to the submit repo to check my change , but no response so far . > Maybe the submit repo is not working currently , not sure about it . > > > Best regards , Matthias > > > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Mittwoch, 11. April 2018 11:20 >> To: 'Alexey Ivanov' ; Magnus Ihse Bursie >> >> Cc: build-dev ; Doerr, Martin >> >> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >>> Was main() exported via map files? >>> >> Seems main was exported , I can find it in jdk10 in e.g. : >> >> make/mapfiles/launchers/mapfile-sparcv9 >> make/mapfiles/launchers/mapfile-x86_64 >> >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>> Sent: Mittwoch, 11. April 2018 11:11 >>> To: Baesken, Matthias ; Magnus Ihse Bursie >>> >>> Cc: build-dev ; Doerr, Martin >>> >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> >>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>> Hi Alexey, yes that's true . >>>> >>>>> Please remove JNIEXPORT from main(): >>>>> src/java.base/share/native/launcher/main.c >>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>> I would prefer to keep it for now . >>>> I notice some comments in our SAPJVM code base about needing >>> JNIEXPORT for main for Solaris (we were running in SAPJVM without >>> mapfiles in the past already). >>>> Maybe that?s related to >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>> >>>> where main is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, "main"); >>>> but I am not sure about this. >>>> So I better keep the JNIEXPORT for the main functions, could be >>> removed in another cleanup if really needed. >>> >>> OK. Let them stay then. >>> Was main() exported via map files? >>> >>> >>> The change looks good to me. >>> >>> Regards, >>> Alexey >>> >>>>> You can reference both yourself and me as >>>>> Contributed-by: mbaesken, aivanov >>>>> when pushing the changeset if you don't mind. >>>>> >>>> Sure . >>>> >>>> Best regards, Matthias >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>> To: Baesken, Matthias ; Magnus Ihse >>> Bursie >>>>> >>>>> Cc: build-dev ; Doerr, Martin >>>>> >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL >> at >>>>> some places in function declarations/implementations >>>>> >>>>> Hi Matthias, >>>>> >>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>> Hello, I had to do another small adjustment to make jimage.hpp/cpp >>> match. Please review : >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>> >>>>> I've successfully built 32 bit Windows with your patch. >>>>> >>>>> >>>>> Please remove JNIEXPORT from main(): >>>>> src/java.base/share/native/launcher/main.c >>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>> >>>>>> With the latest webrev I could finally build jdk/jdk successfully on both >>> win32bit and win64 bit. >>>>>> Thanks again to Alexey to provide the incorporated patch . >>>>> You can reference both yourself and me as >>>>> Contributed-by: mbaesken, aivanov >>>>> when pushing the changeset if you don't mind. >>>>> >>>>> >>>>> Regards, >>>>> Alexey >>>>> >>>>>> Best regards, Matthias >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>> Bursie >>>>>>> >>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>> >>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >> JNICALL >>> at >>>>>>> some places in function declarations/implementations >>>>>>> >>>>>>> Hi Matthias, >>>>>>> >>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>> Hi Alexey, thanks for the diff provided by you, and for the >>>>> explanations >>>>>>> . >>>>>>>> I created a second webrev : >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>> >>>>>>>> - it adds the diff provided by you (hope that?s fine with you) >>>>>>> Yes, that's fine with me. >>>>>>> There could be only one author ;) >>>>>>> >>>>>>>> - changes 2 launchers >> src/java.base/share/native/launcher/main.c >>>>> and >>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>> similar >>>>>>> issues after mapfile removal for exes >>>>>>> >>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>> It wasn't exported, and it shouldn't be. >>>>>>> >>>>>>> Regards, >>>>>>> Alexey >>>>>>> >>>>>>>> Best regards , Matthias From philip.race at oracle.com Thu Apr 12 20:42:59 2018 From: philip.race at oracle.com (Phil Race) Date: Thu, 12 Apr 2018 13:42:59 -0700 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <7c5e68c2a023490e96ce6452fbda1700@sap.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> Message-ID: How can JNIEXPORT be different between 32 bit & 64 bit ? I'm sure you saw compilation errors but I don't get why it failed for 32 only. JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't explain why the 32 bit compiler would complain about inconsistent application of __declspec(dllexport) - ie JNIEXPORT. Or is that part (adding JNIEXPORT) pure clean up and the compilation errors were all down to JNICALL ? I was a bit puzzled at the removals I saw here : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html .. I needed to look at the whole file to realise that you were removing a duplicate declaration. -phil. On 04/12/2018 04:04 AM, Baesken, Matthias wrote: > Hi Alan , this is the up to date webrev . > However we want to add Alexey Ivanov as additional author . > >> As I read it, this changes the calling convention of these functions on >> 32-bit Windows but it will have no impact on 64-bit Windows (as >> __stdcall is ignored) or other platforms, is that correct? >> > The change adds JNIEXPORT at some places where it is ben forgotten , for example : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html > > This might have potential impact on other platforms (fixes the mismatches) . > > Best regards, Matthias > > > > >> -----Original Message----- >> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >> Sent: Donnerstag, 12. April 2018 12:54 >> To: Baesken, Matthias ; Magnus Ihse Bursie >> >> Cc: build-dev at openjdk.java.net; Doerr, Martin ; >> core-libs-dev at openjdk.java.net >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >> Adding core-libs-dev as this is change code in libjava, libzip, >> libjimage, ... >> >> Can you confirm that this is the up to date webrev: >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >> >> As I read it, this changes the calling convention of these functions on >> 32-bit Windows but it will have no impact on 64-bit Windows (as >> __stdcall is ignored) or other platforms, is that correct? >> >> -Alan >> >> >> On 06/04/2018 14:20, Baesken, Matthias wrote: >>> Hello, I just noticed 2 additonal issues regarding mapfile-removal : >>> >>> >>> 1. The follow up change that removed mapfiles for exes as well >> leads on Win32 bit to this link error : >>> Creating library >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and object >> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp >>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main >> referenced in function ___tmainCRTStartup >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : >> fatal error LNK1120: 1 unresolved externals >>> >>> Looks like we cannot have JNICALL in main.c : >>> >>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c >>> --- a/src/java.base/share/native/launcher/main.c Thu Apr 05 14:39:04 >> 2018 -0700 >>> +++ b/src/java.base/share/native/launcher/main.c Fri Apr 06 15:16:40 >> 2018 +0200 >>> @@ -93,7 +93,7 @@ >>> __initenv = _environ; >>> >>> #else /* JAVAW */ >>> -JNIEXPORT int JNICALL >>> +JNIEXPORT int >>> main(int argc, char **argv) >>> { >>> int margc; >>> >>> >>> >>> 1. Zip-library has runtime issues when symbols are resolved in >> src/hotspot/share/classfile/classLoader.cpp. >>> I added the declaration of the missing symbol, this seems to fix it . >>> >>> >>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h >>> --- a/src/java.base/share/native/libzip/zip_util.h Thu Apr 05 14:39:04 >> 2018 -0700 >>> +++ b/src/java.base/share/native/libzip/zip_util.h Fri Apr 06 15:16:40 >> 2018 +0200 >>> @@ -284,4 +284,7 @@ >>> JNIEXPORT jboolean JNICALL >>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong outLen, char >> **pmsg); >>> +JNIEXPORT jint JNICALL >>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); >>> + >>> >>> >>> Should I prepare another bug, or add this to the existing one and post a >> second webrev ? >>> Best regards, Matthias >>> >>> >>> From: Baesken, Matthias >>> Sent: Freitag, 6. April 2018 09:54 >>> To: 'Magnus Ihse Bursie' >>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in >> function declarations/implementations - was : RE: missing JNIEXPORT / >> JNICALL at some places in function declarations/implementations >>> Hello, please review : >>> >>> Bug : >>> >>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>> >>> change : >>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ >>> >>> mostly I added JNIEXPORT / JNICALL at some places where the win32bit >> build missed it . >>> A difference is >> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >>> Where I removed a few declarations (one decl with one without >> JNIEXPORT / JNICALL ? looked a bit strange ) . >>> Best regards , Matthias >>> >>> >>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >>> Sent: Donnerstag, 5. April 2018 17:45 >>> To: Baesken, Matthias >> > >>> Cc: build-dev at openjdk.java.net; >> Doerr, Martin > >>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations >>> That's most likely a result of the new JNIEXPORT I added as part of the >> mapfile removal. >>> I tried to match header file and C file, but I can certainly have missed cases. >> If I didn't get any warnings, it was hard to know what I missed. >>> Please do submit your patch. >>> >>> I'm a bit surprised 32-bit Window is still buildable. :) >>> >>> /Magnus >>> >>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias >> >: >>> Hello, we noticed that at a number of places in the coding , the >> JNIEXPORT and/or JNICALL modifiers do not match when one compares >> the declaration and >>> The implementation of functions. >>> While this is ok on most platforms, it seems to fail on Windows 32 bit and >> leads to errors like this one : >>> >> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml >> ib_ImageConvKernelConvert.c(87) : error C2373: >> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type modifiers >> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml >> ib_image_proto.h(2630) : see declaration of >> 'j2d_mlib_ImageConvKernelConvert' >>> (there are quite a few of these e.g. in mlib / splashscreen etc.) >>> >>> >>> Another example is this one : >>> >>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp >>> --- a/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 09:55:16 >> 2018 +0200 >>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 >> 17:07:40 2018 +0200 >>> @@ -126,7 +126,7 @@ >>> * JImageLocationRef location = (*JImageFindResource)(image, >>> * "java.base", "9.0", "java/lang/String.class", &size); >>> */ >>> -extern "C" JNIEXPORT JImageLocationRef >> JIMAGE_FindResource(JImageFile* jimage, >>> +extern "C" JNIEXPORT JImageLocationRef JNICALL >> JIMAGE_FindResource(JImageFile* jimage, >>> const char* module_name, const char* version, const char* name, >>> jlong* size); >>> >>> >>> Is there some generic way to get the same declarations / impementations >> in the code ? >>> Or should I just add a patch with my findings ? >>> >>> Best regards, Matthias >>> From Sergey.Bylokhov at oracle.com Thu Apr 12 21:33:17 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Apr 2018 14:33:17 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM In-Reply-To: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> References: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> Message-ID: Hi, Alexey. Since the test requires 1g of memory, should we use this tag?: * @requires os.maxMemory >= 1g Otherwise the test may fail on start if amount of memory is not sufficient. On 12/04/2018 08:25, Alexey Ivanov wrote: > Hi, > > Please review the fix for jdk11: > > bug: https://bugs.openjdk.java.net/browse/JDK-8201433 > webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.00/ > > > When the JVM is run with limited amount of memory, initCubemap function > called from BufImg_SetupICM can return NULL. It can lead to a crash. It > usually happens when native memory is exhausted and malloc fails. In > this state, JVM itself is not stable. > > Adding NULL-check can prevent the crash in this particular place. > However, if the app continues, since native memory is exhausted and > malloc fails, JVM can still crash in another place. > > > Thank you in advance. > > Regards, > Alexey -- Best regards, Sergey. From alexey.ivanov at oracle.com Thu Apr 12 21:40:20 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 22:40:20 +0100 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <06efbd83-9a48-bccd-686f-7e12fc893b2a@oracle.com> <35e12d6d6eb24d88aadaf10e0229dd48@sap.com> <8ED8CAEA-5215-4FDF-923B-598AA98FB7E2@oracle.com> <5146b9330edd44b483780587aca1757c@sap.com> <99420e261ef347578bb8099a48d6b7ec@sap.com> <5693830fbf6747d9a51e9cf374f63e18@sap.com> <7d4d9d7b-0546-b4ed-c400-0eaefee28853@oracle.com> <3520f157a7d14a118a584fdeb226381e@sap.com> <609cd9c0-94e1-3f84-d8d5-e8ce052c80d6@oracle.com> Message-ID: On 12/04/2018 19:38, Phil Race wrote: > I was just directed to this look at this change. > I don't know why it is being reviewed exclusively on build-dev since no > build files are being changed. My bad! I tried to engage core-libs when the patch was ready but I completely overlooked the fact that 2d libs were also affected by this change and I didn't cc to 2d-dev. > 50% of it should have been sent to 2d-dev and the rest on core-libs + > hotspot .. > > Is this the current version of the change : > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? Yes, it's the latest version to the best of my knowledge. Regards, Alexey > > -phil. > > On 04/12/2018 12:49 AM, Baesken, Matthias wrote: >> Hi,? could? someone please? sponsor? the change? now ? >> >> And? could someone please check? what happened? to the submit-repo ? >> Yesterday I pushed to? the submit repo? to?? check my? change ,? but? >> no? response?? so far . >> Maybe? the submit repo? is not working currently? ,? not sure about it . >> >> >> Best regards , Matthias >> >> >> >> >>> -----Original Message----- >>> From: Baesken, Matthias >>> Sent: Mittwoch, 11. April 2018 11:20 >>> To: 'Alexey Ivanov' ; Magnus Ihse Bursie >>> >>> Cc: build-dev ; Doerr, Martin >>> >>> Subject: RE: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>>> Was main() exported via map files? >>>> >>> Seems main was exported , I can find it in jdk10? in? e.g.? : >>> >>> make/mapfiles/launchers/mapfile-sparcv9 >>> make/mapfiles/launchers/mapfile-x86_64 >>> >>> >>> Best regards, Matthias >>> >>> >>>> -----Original Message----- >>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>> Sent: Mittwoch, 11. April 2018 11:11 >>>> To: Baesken, Matthias ; Magnus Ihse Bursie >>>> >>>> Cc: build-dev ; Doerr, Martin >>>> >>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>> JNICALL at >>>> some places in function declarations/implementations >>>> >>>> >>>> On 11/04/2018 08:44, Baesken, Matthias wrote: >>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>> Hi? Alexey, yes that's true . >>>>> >>>>>> Please remove JNIEXPORT from main(): >>>>>> src/java.base/share/native/launcher/main.c >>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>> I would? prefer to keep it for now . >>>>> I notice? some? comments? in our SAPJVM code base? about needing >>>> JNIEXPORT for? main? for Solaris? (we were running? in SAPJVM without >>>> mapfiles in the past already). >>>>> Maybe? that?s related to >>>>> >>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>> >>>>> where main? is dlsym-ed : fptr = (int (*)())dlsym(RTLD_DEFAULT, >>>>> "main"); >>>>> but I am not sure about this. >>>>> So I better keep? the JNIEXPORT? for the main functions, could be >>>> removed in another? cleanup? if really needed. >>>> >>>> OK. Let them stay then. >>>> Was main() exported via map files? >>>> >>>> >>>> The change looks good to me. >>>> >>>> Regards, >>>> Alexey >>>> >>>>>> You can reference both yourself and me as >>>>>> Contributed-by: mbaesken, aivanov >>>>>> when pushing the changeset if you don't mind. >>>>>> >>>>> Sure . >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>> Sent: Dienstag, 10. April 2018 21:34 >>>>>> To: Baesken, Matthias ; Magnus Ihse >>>> Bursie >>>>>> >>>>>> Cc: build-dev ; Doerr, Martin >>>>>> >>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>> function >>>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL >>> at >>>>>> some places in function declarations/implementations >>>>>> >>>>>> Hi Matthias, >>>>>> >>>>>> On 10/04/2018 11:14, Baesken, Matthias wrote: >>>>>>> Hello,? I? had to? do another small adjustment to make >>>>>>> jimage.hpp/cpp >>>> match. Please review : >>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>> JIMAGE_FindResource doesn't have JNICALL modifier now, does it? >>>>>> >>>>>> I've successfully built 32 bit Windows with your patch. >>>>>> >>>>>> >>>>>> Please remove JNIEXPORT from main(): >>>>>> src/java.base/share/native/launcher/main.c >>>>>> src/jdk.pack/share/native/unpack200/main.cpp >>>>>> >>>>>>> With the latest webrev I could finally build jdk/jdk >>>>>>> successfully on both >>>> win32bit and win64 bit. >>>>>>> Thanks again? to Alexey? to provide? the?? incorporated patch . >>>>>> You can reference both yourself and me as >>>>>> Contributed-by: mbaesken, aivanov >>>>>> when pushing the changeset if you don't mind. >>>>>> >>>>>> >>>>>> Regards, >>>>>> Alexey >>>>>> >>>>>>> Best regards, Matthias >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>>>>>>> Sent: Montag, 9. April 2018 17:14 >>>>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>>> Bursie >>>>>>>> >>>>>>>> Cc: build-dev ; Doerr, Martin >>>>>>>> >>>>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>>> function >>>>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>> JNICALL >>>> at >>>>>>>> some places in function declarations/implementations >>>>>>>> >>>>>>>> Hi Matthias, >>>>>>>> >>>>>>>> On 09/04/2018 15:38, Baesken, Matthias wrote: >>>>>>>>> Hi? Alexey,??? thanks? for the diff provided by you, and? for? >>>>>>>>> the >>>>>> explanations >>>>>>>> . >>>>>>>>> I created? a second? webrev : >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.1/ >>>>>>>>> >>>>>>>>> -?? it? adds? the diff? provided by you??? (hope that?s fine >>>>>>>>> with you) >>>>>>>> Yes, that's fine with me. >>>>>>>> There could be only one author ;) >>>>>>>> >>>>>>>>> -??? changes? 2 launchers >>> src/java.base/share/native/launcher/main.c >>>>>> and >>>>>>>> src/jdk.pack/share/native/unpack200/main.cpp where we face >>>> similar >>>>>>>> issues after mapfile removal for exes >>>>>>>> >>>>>>>> I'd rather remove both JNIEXPORT and JNICALL from main(). >>>>>>>> It wasn't exported, and it shouldn't be. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Alexey >>>>>>>> >>>>>>>>> Best regards , Matthias > From alexey.ivanov at oracle.com Thu Apr 12 21:53:10 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 22:53:10 +0100 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> Message-ID: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> On 12/04/2018 21:42, Phil Race wrote: > How can JNIEXPORT be different between 32 bit & 64 bit ? > I'm sure you saw compilation errors but I don't get why it failed for > 32 only. > > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't > explain why the 32 bit compiler would complain about inconsistent > application > of __declspec(dllexport) - ie JNIEXPORT. > > Or is that part (adding JNIEXPORT) pure clean up and the compilation > errors were all down to JNICALL ? Adding missing JNIEXPORT is for cleanup only. The compiler complained about mismatched JNICALL / non-JNICALL declarations as the macro changes calling convention from the default __cdecl? to __stdcall on 32 bit Windows. Another issue is that __stdcall decorates the functions: prefixes with underscore and postfixes with @ + size of parameters. Because of the decorations, classLoader.cpp can't lookup the required functions by name from zip.dll and jimage.dll. The functions are exported but with different name. I hope this information adds more details to the picture. > I was a bit puzzled at the removals I saw here : > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h.udiff.html > > > .. I needed to look at the whole file to realise that you were > removing a duplicate > declaration. That was tricky. I could have been mentioned in the review. Regards, Alexey > > -phil. > > On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >> Hi? Alan , this is the up to date webrev . >> However we want to add?? Alexey?? Ivanov? as additional? author . >> >>> As I read it, this changes the calling convention of these functions on >>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>> __stdcall is ignored) or other platforms, is that correct? >>> >> The? change adds? JNIEXPORT?? at some places? where it is? ben >> forgotten , for example : >> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >> >> >> This might have? potential? impact? on other platforms?? (fixes the >> mismatches) . >> >> Best regards, Matthias >> >> >> >> >>> -----Original Message----- >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>> Sent: Donnerstag, 12. April 2018 12:54 >>> To: Baesken, Matthias ; Magnus Ihse Bursie >>> >>> Cc: build-dev at openjdk.java.net; Doerr, Martin ; >>> core-libs-dev at openjdk.java.net >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> Adding core-libs-dev as this is change code in libjava, libzip, >>> libjimage, ... >>> >>> Can you confirm that this is the up to date webrev: >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>> >>> As I read it, this changes the calling convention of these functions on >>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>> __stdcall is ignored) or other platforms, is that correct? >>> >>> -Alan >>> >>> >>> On 06/04/2018 14:20, Baesken, Matthias wrote: >>>> Hello, I just noticed? 2? additonal issues? regarding >>>> mapfile-removal : >>>> >>>> >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes? >>>> as well >>> leads on Win32 bit? to? this link error : >>>> ??? Creating library >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and >>> object >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main >>> referenced in function ___tmainCRTStartup >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe : >>> fatal error LNK1120: 1 unresolved externals >>>> >>>> Looks like we? cannot have?? JNICALL?? in main.c?? : >>>> >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05 >>>> 14:39:04 >>> 2018 -0700 >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06 >>>> 15:16:40 >>> 2018 +0200 >>>> @@ -93,7 +93,7 @@ >>>> ?????? __initenv = _environ; >>>> >>>> #else /* JAVAW */ >>>> -JNIEXPORT int JNICALL >>>> +JNIEXPORT int >>>> main(int argc, char **argv) >>>> { >>>> ?????? int margc; >>>> >>>> >>>> >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are >>>> resolved? in >>> src/hotspot/share/classfile/classLoader.cpp. >>>> I added? the declaration of the missing symbol, this seems to fix it . >>>> >>>> >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05 >>>> 14:39:04 >>> 2018 -0700 >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06 >>>> 15:16:40 >>> 2018 +0200 >>>> @@ -284,4 +284,7 @@ >>>> JNIEXPORT jboolean JNICALL >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong >>>> outLen, char >>> **pmsg); >>>> +JNIEXPORT jint JNICALL >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); >>>> + >>>> >>>> >>>> Should I? prepare? another? bug,? or? add this to the existing one >>>> and??? post a >>> second webrev ? >>>> Best regards, Matthias >>>> >>>> >>>> From: Baesken, Matthias >>>> Sent: Freitag, 6. April 2018 09:54 >>>> To: 'Magnus Ihse Bursie' >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function declarations/implementations - was : RE: missing JNIEXPORT / >>> JNICALL at some places in function declarations/implementations >>>> Hello, please review : >>>> >>>> Bug : >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8201226 >>>> >>>> change : >>>> >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ >>>> >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the win32bit >>> build missed it . >>>> A difference is >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h >>>> Where I removed?? a few? declarations (one? decl?? with one without >>> JNIEXPORT / JNICALL ? looked a bit strange ) . >>>> Best regards , Matthias >>>> >>>> >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] >>>> Sent: Donnerstag, 5. April 2018 17:45 >>>> To: Baesken, Matthias >>> > >>>> Cc: build-dev at openjdk.java.net; >>> Doerr, Martin > >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function >>> declarations/implementations >>>> That's most likely a result of the new JNIEXPORT I added as part of >>>> the >>> mapfile removal. >>>> I tried to match header file and C file, but I can certainly have >>>> missed cases. >>> If I didn't get any warnings, it was hard to know what I missed. >>>> Please do submit your patch. >>>> >>>> I'm a bit surprised 32-bit Window is still buildable. :) >>>> >>>> /Magnus >>>> >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias >>> >: >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one compares >>> the declaration and >>>> The implementation of functions. >>>> While this is ok on most platforms, it seems to fail on Windows 32 >>>> bit and >>> leads to errors like this one : >>>> >>> e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml >>> >>> ib_ImageConvKernelConvert.c(87) : error C2373: >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type >>> modifiers >>> e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml >>> >>> ib_image_proto.h(2630) : see declaration of >>> 'j2d_mlib_ImageConvKernelConvert' >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.) >>>> >>>> >>>> Another example is this one : >>>> >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05 >>>> 09:55:16 >>> 2018 +0200 >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 >>> 17:07:40 2018 +0200 >>>> @@ -126,7 +126,7 @@ >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image, >>>> ??? *??????????????????????????????? "java.base", "9.0", >>>> "java/lang/String.class", &size); >>>> ??? */ >>>> -extern "C" JNIEXPORT JImageLocationRef >>> JIMAGE_FindResource(JImageFile* jimage, >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL >>> JIMAGE_FindResource(JImageFile* jimage, >>>> ?????????? const char* module_name, const char* version, const >>>> char* name, >>>> ?????????? jlong* size); >>>> >>>> >>>> Is there some generic way to get? the? same? declarations / >>>> impementations >>> in the code? ? >>>> Or should I just add a patch with my findings ? >>>> >>>> Best regards, Matthias >>>> > From alexey.ivanov at oracle.com Thu Apr 12 22:15:55 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Thu, 12 Apr 2018 23:15:55 +0100 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM In-Reply-To: References: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> Message-ID: <975dff93-d8fd-e245-eebe-059281c7bda9@oracle.com> Hi Sergey, Thank you for your review. Please take a look at the updated webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.01/ On 12/04/2018 22:33, Sergey Bylokhov wrote: > Hi, Alexey. > Since the test requires 1g of memory, should we use this tag?: > ?* @requires os.maxMemory >= 1g > Otherwise the test may fail on start if amount of memory is not > sufficient. It makes sense to add it so that the test is skipped if there's not enough of memory. However, I think the actual requirement is >= 2G as it needs 1G for Java heap and it needs native memory for images and for other purposes. The test exhausts the available native memory to make malloc fail. The amount of used memory reaches close to 2G before it fails. Regards, Alexey > > On 12/04/2018 08:25, Alexey Ivanov wrote: >> Hi, >> >> Please review the fix for jdk11: >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8201433 >> webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.00/ >> >> >> When the JVM is run with limited amount of memory, initCubemap >> function called from BufImg_SetupICM can return NULL. It can lead to >> a crash. It usually happens when native memory is exhausted and >> malloc fails. In this state, JVM itself is not stable. >> >> Adding NULL-check can prevent the crash in this particular place. >> However, if the app continues, since native memory is exhausted and >> malloc fails, JVM can still crash in another place. >> >> >> Thank you in advance. >> >> Regards, >> Alexey From srloomis at us.ibm.com Fri Apr 13 00:32:47 2018 From: srloomis at us.ibm.com (Steven R Loomis) Date: Fri, 13 Apr 2018 00:32:47 +0000 Subject: [OpenJDK 2D-Dev] Proposal: Unicode Variation Selector In-Reply-To: <79127e03-f9c3-5138-bf4e-60a911b3a9b0@oracle.com> References: <79127e03-f9c3-5138-bf4e-60a911b3a9b0@oracle.com>, Message-ID: An HTML attachment was scrubbed... URL: From srloomis at us.ibm.com Fri Apr 13 00:33:19 2018 From: srloomis at us.ibm.com (Steven R Loomis) Date: Fri, 13 Apr 2018 00:33:19 +0000 Subject: [OpenJDK 2D-Dev] Proposal: Unicode Variation Selector In-Reply-To: <79127e03-f9c3-5138-bf4e-60a911b3a9b0@oracle.com> References: <79127e03-f9c3-5138-bf4e-60a911b3a9b0@oracle.com>, Message-ID: An HTML attachment was scrubbed... URL: From matthias.baesken at sap.com Fri Apr 13 05:48:23 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 13 Apr 2018 05:48:23 +0000 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: Hi Phil/Alexey, thanks for adding the other lists . > Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? Yes. Best regards, Matthias > -----Original Message----- > From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] > Sent: Donnerstag, 12. April 2018 23:53 > To: Phil Race ; Baesken, Matthias > ; Alan Bateman ; > Magnus Ihse Bursie > Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, > Martin ; 2d-dev <2d-dev at openjdk.java.net>; > hotspot-dev > Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function > declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > some places in function declarations/implementations > > > On 12/04/2018 21:42, Phil Race wrote: > > How can JNIEXPORT be different between 32 bit & 64 bit ? > > I'm sure you saw compilation errors but I don't get why it failed for > > 32 only. > > > > JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't > > explain why the 32 bit compiler would complain about inconsistent > > application > > of __declspec(dllexport) - ie JNIEXPORT. > > > > Or is that part (adding JNIEXPORT) pure clean up and the compilation > > errors were all down to JNICALL ? > > Adding missing JNIEXPORT is for cleanup only. > > The compiler complained about mismatched JNICALL / non-JNICALL > declarations as the macro changes calling convention from the default > __cdecl? to __stdcall on 32 bit Windows. > > Another issue is that __stdcall decorates the functions: prefixes with > underscore and postfixes with @ + size of parameters. Because of the > decorations, classLoader.cpp can't lookup the required functions by name > from zip.dll and jimage.dll. The functions are exported but with > different name. > > I hope this information adds more details to the picture. > > > I was a bit puzzled at the removals I saw here : > > > > > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto > p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html > > > > > > .. I needed to look at the whole file to realise that you were > > removing a duplicate > > declaration. > > That was tricky. I could have been mentioned in the review. > > > Regards, > Alexey > > > > > -phil. > > > > On 04/12/2018 04:04 AM, Baesken, Matthias wrote: > >> Hi? Alan , this is the up to date webrev . > >> However we want to add?? Alexey?? Ivanov? as additional? author . > >> > >>> As I read it, this changes the calling convention of these functions on > >>> 32-bit Windows but it will have no impact on 64-bit Windows (as > >>> __stdcall is ignored) or other platforms, is that correct? > >>> > >> The? change adds? JNIEXPORT?? at some places? where it is? ben > >> forgotten , for example : > >> > >> > http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto > p/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html > >> > >> > >> This might have? potential? impact? on other platforms?? (fixes the > >> mismatches) . > >> > >> Best regards, Matthias > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > >>> Sent: Donnerstag, 12. April 2018 12:54 > >>> To: Baesken, Matthias ; Magnus Ihse > Bursie > >>> > >>> Cc: build-dev at openjdk.java.net; Doerr, Martin > ; > >>> core-libs-dev at openjdk.java.net > >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in > >>> function > >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at > >>> some places in function declarations/implementations > >>> > >>> Adding core-libs-dev as this is change code in libjava, libzip, > >>> libjimage, ... > >>> > >>> Can you confirm that this is the up to date webrev: > >>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ > >>> > >>> As I read it, this changes the calling convention of these functions on > >>> 32-bit Windows but it will have no impact on 64-bit Windows (as > >>> __stdcall is ignored) or other platforms, is that correct? > >>> > >>> -Alan > >>> > >>> > >>> On 06/04/2018 14:20, Baesken, Matthias wrote: > >>>> Hello, I just noticed? 2? additonal issues? regarding > >>>> mapfile-removal : > >>>> > >>>> > >>>> ??? 1.? The?? follow up change? that removed?? mapfiles for exes > >>>> as well > >>> leads on Win32 bit? to? this link error : > >>>> ??? Creating library > >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.lib and > >>> object > >>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java/java.exp > >>>> LIBCMT.lib(crt0.obj) : error LNK2019: unresolved external symbol _main > >>> referenced in function ___tmainCRTStartup > >>>> C:/JVM/jdk_jdk_ntintel/support/native/java.base/java_objs/java.exe > : > >>> fatal error LNK1120: 1 unresolved externals > >>>> > >>>> Looks like we? cannot have?? JNICALL?? in main.c?? : > >>>> > >>>> diff -r 4f6887eade94 src/java.base/share/native/launcher/main.c > >>>> --- a/src/java.base/share/native/launcher/main.c??????? Thu Apr 05 > >>>> 14:39:04 > >>> 2018 -0700 > >>>> +++ b/src/java.base/share/native/launcher/main.c??????? Fri Apr 06 > >>>> 15:16:40 > >>> 2018 +0200 > >>>> @@ -93,7 +93,7 @@ > >>>> ?????? __initenv = _environ; > >>>> > >>>> #else /* JAVAW */ > >>>> -JNIEXPORT int JNICALL > >>>> +JNIEXPORT int > >>>> main(int argc, char **argv) > >>>> { > >>>> ?????? int margc; > >>>> > >>>> > >>>> > >>>> ??? 1.? Zip-library? has runtime issues?? when? symbols? are > >>>> resolved? in > >>> src/hotspot/share/classfile/classLoader.cpp. > >>>> I added? the declaration of the missing symbol, this seems to fix it . > >>>> > >>>> > >>>> diff -r 4f6887eade94 src/java.base/share/native/libzip/zip_util.h > >>>> --- a/src/java.base/share/native/libzip/zip_util.h????? Thu Apr 05 > >>>> 14:39:04 > >>> 2018 -0700 > >>>> +++ b/src/java.base/share/native/libzip/zip_util.h????? Fri Apr 06 > >>>> 15:16:40 > >>> 2018 +0200 > >>>> @@ -284,4 +284,7 @@ > >>>> JNIEXPORT jboolean JNICALL > >>>> ZIP_InflateFully(void *inBuf, jlong inLen, void *outBuf, jlong > >>>> outLen, char > >>> **pmsg); > >>>> +JNIEXPORT jint JNICALL > >>>> +ZIP_CRC32(jint crc, const jbyte *buf, jint len); > >>>> + > >>>> > >>>> > >>>> Should I? prepare? another? bug,? or? add this to the existing one > >>>> and??? post a > >>> second webrev ? > >>>> Best regards, Matthias > >>>> > >>>> > >>>> From: Baesken, Matthias > >>>> Sent: Freitag, 6. April 2018 09:54 > >>>> To: 'Magnus Ihse Bursie' > >>>> Cc: build-dev at openjdk.java.net; Doerr, Martin > > >>>> Subject: RFR: 8201226 missing JNIEXPORT / JNICALL at some places in > >>> function declarations/implementations - was : RE: missing JNIEXPORT / > >>> JNICALL at some places in function declarations/implementations > >>>> Hello, please review : > >>>> > >>>> Bug : > >>>> > >>>> https://bugs.openjdk.java.net/browse/JDK-8201226 > >>>> > >>>> change : > >>>> > >>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226/ > >>>> > >>>> mostly I added? JNIEXPORT / JNICALL at some places? where the > win32bit > >>> build missed it . > >>>> A difference is > >>> src/java.desktop/share/native/libsplashscreen/splashscreen_impl.h > >>>> Where I removed?? a few? declarations (one? decl?? with one without > >>> JNIEXPORT / JNICALL ? looked a bit strange ) . > >>>> Best regards , Matthias > >>>> > >>>> > >>>> From: Magnus Ihse Bursie [mailto:magnus.ihse.bursie at oracle.com] > >>>> Sent: Donnerstag, 5. April 2018 17:45 > >>>> To: Baesken, Matthias > >>> > > >>>> Cc: build-dev at openjdk.java.net; > >>> Doerr, Martin > > > >>>> Subject: Re: missing JNIEXPORT / JNICALL at some places in function > >>> declarations/implementations > >>>> That's most likely a result of the new JNIEXPORT I added as part of > >>>> the > >>> mapfile removal. > >>>> I tried to match header file and C file, but I can certainly have > >>>> missed cases. > >>> If I didn't get any warnings, it was hard to know what I missed. > >>>> Please do submit your patch. > >>>> > >>>> I'm a bit surprised 32-bit Window is still buildable. :) > >>>> > >>>> /Magnus > >>>> > >>>> 5 apr. 2018 kl. 17:20 skrev Baesken, Matthias > >>> >: > >>>> Hello, we noticed? that? at a number of places in the coding? ,?? the > >>> JNIEXPORT and/or?? JNICALL modifiers?? do not match? when one > compares > >>> the declaration and > >>>> The implementation of functions. > >>>> While this is ok on most platforms, it seems to fail on Windows 32 > >>>> bit and > >>> leads to errors like this one : > >>>> > >>> > e:/priv/openjdk/repos/jdk/src/java.desktop/share/native/libmlib_image/ml > >>> > >>> ib_ImageConvKernelConvert.c(87) : error C2373: > >>> 'j2d_mlib_ImageConvKernelConvert' : redefinition; different type > >>> modifiers > >>> > e:\priv\openjdk\repos\jdk\src\java.desktop\share\native\libmlib_image\ml > >>> > >>> ib_image_proto.h(2630) : see declaration of > >>> 'j2d_mlib_ImageConvKernelConvert' > >>>> (there are quite a few of these e.g. in mlib? / splashscreen etc.) > >>>> > >>>> > >>>> Another example is this one : > >>>> > >>>> diff -r 4d98473ed33e src/java.base/share/native/libjimage/jimage.hpp > >>>> --- a/src/java.base/share/native/libjimage/jimage.hpp? Thu Apr 05 > >>>> 09:55:16 > >>> 2018 +0200 > >>>> +++ b/src/java.base/share/native/libjimage/jimage.hpp Thu Apr 05 > >>> 17:07:40 2018 +0200 > >>>> @@ -126,7 +126,7 @@ > >>>> ??? *?? JImageLocationRef location = (*JImageFindResource)(image, > >>>> ??? *??????????????????????????????? "java.base", "9.0", > >>>> "java/lang/String.class", &size); > >>>> ??? */ > >>>> -extern "C" JNIEXPORT JImageLocationRef > >>> JIMAGE_FindResource(JImageFile* jimage, > >>>> +extern "C" JNIEXPORT JImageLocationRef JNICALL > >>> JIMAGE_FindResource(JImageFile* jimage, > >>>> ?????????? const char* module_name, const char* version, const > >>>> char* name, > >>>> ?????????? jlong* size); > >>>> > >>>> > >>>> Is there some generic way to get? the? same? declarations / > >>>> impementations > >>> in the code? ? > >>>> Or should I just add a patch with my findings ? > >>>> > >>>> Best regards, Matthias > >>>> > > From jayathirth.d.v at oracle.com Fri Apr 13 08:31:07 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 13 Apr 2018 01:31:07 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> <94cbe6b3-0459-4542-8f66-4b00a0905740@default> Message-ID: <3f81e593-4f58-4b0e-a52c-ad05d92299dd@default> Hi Phil, Thanks for your inputs. I have updated the code to reflect the changes mentioned by you and changed test case to use ByteArrayInput/OutputStream. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6788458/webrev.08/ Regards, Jay -----Original Message----- From: Phil Race Sent: Wednesday, April 11, 2018 10:23 PM To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images http://cr.openjdk.java.net/~jdv/6788458/webrev.07/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java.udiff.html There's an extra line added at the end which you can remove. Why do the tests needs to create temp disk files ? Can't we do this all with ByteArrayInput/OutputStream ? Less worry about clean up there. I note that this 286 boolean tRNSTransparentPixelPresent = 1287 theImage.getSampleModel().getNumBands() == inputBands + 1 && 1288 metadata.hasTransparentColor(); is evaluated for each row when I expect it only needs to be evaluated once for the whole decode pass. But the overhed is presumably low and it is next to the use so I think it should be OK as is. However the code that does the transparent per-pixel settings does seem needlessly wasteful. These can be moved outside at least the entire row decode : final int[] temp = new int[inputBands + 1]; final int opaque = (bitDepth < 16) ? 255 : 65535; Note that I added final to them .. Also array accesses are (relatively) slow but since you need an array to pass to setPixel and there's only two accesses I don't see how we can improve on that here by assigning the values from the ps array to local variables. -phil. On 04/09/2018 11:19 PM, Jayathirth D V wrote: > HI Prahalad, > > Thanks for your inputs. > > Regarding- > Few minor corrections to PNGImageReader- . Line: 1310 > . This missed my eye in the last review. > . We could create int[] temp outside the for loop. I tried this with your changes & it works. > . It's an optimization so that we don't end up creating int[] array for every pixel in the row. > > Before sending webrev.06, I actually made similar changes of moving temp[] creation and/or calculating "opaque" to outside of for loop. > But this will cause creation of temp[] and/ or calculation of "opaque" for each row in all the cases where there is no RGB/Gray & tRNS combination. So I reverted those change before sending webrev.06. > I would like to keep all the calculation specific to RGB/Gray & tRNS combination in its own code flow. > > Other modifications are made. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.07/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Monday, April 09, 2018 2:23 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > I looked into the latest code changes. > The code changes are good. > > Few minor corrections to PNGImageReader- . Line: 1310 > . This missed my eye in the last review. > . We could create int[] temp outside the for loop. I tried this with your changes & it works. > . It's an optimization so that we don't end up creating int[] array for every pixel in the row. > > . Line: 1320, 1329 > . Align the opening { on the same line as the if statement. > > . Line: 1479 > . Correct the indentation of the expression within if condition. > . A suggestion that could help: > if ((theImage.getSampleModel().getNumBands() > == inputBandsForColorType[colorType] + 1) > && metadata.hasTransparentColor()) { > // code block > checkReadParamBandSettings(param, > ... > } > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Friday, April 06, 2018 5:19 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hi Prahalad, > > Thanks for your inputs. > > Regarding : > File: PNGImageReader.java > Line: 1329, 1342 > . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. > . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. > int[] temp = new int[inputBands + 1]; > int opaque = (bitDepth < 16) ? 255 : 65535; > Arrays.fill(temp, opaque); > . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. > > I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. > > Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: > int[] temp = new int[inputBands + 1]; > temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if > (metadata.tRNS_colorType == PNG_COLOR_RGB) { > > I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. > So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. > > All other changes are updated. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Friday, April 06, 2018 1:42 PM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > Good day to you. > > I looked into the latest changes. > The code changes are nearly complete. Just a few tweaks. > > File: PNGImageReader.java > Line: 1280 > Rephrase from: > /* > * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY > * if we have transparent pixel information from tRNS chunk > * we need to consider that also and store proper information > * in alpha channel. > * > * Also we create destination image with extra alpha channel > * in getImageTypes() when we have tRNS chunk for colorType > * PNG_COLOR_RGB or PNG_COLOR_GRAY. > */ > Rephrase to: > /* > * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY > * that contain a specific transparent color (given by tRNS > * chunk), we compare the decoded pixel color with the color > * given by tRNS chunk to set the alpha on the destination. > */ > > File: PNGImageReader.java > Line: 1588 > Rephrase from: > /* > * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we > * have transparent pixel information in tRNS chunk > * we create destination image having alpha channel. > */ > > Rephrase to: > /* > * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that > * contain a specific transparent color (given by tRNS chunk), we add > * ImageTypeSpecifier(s) that support transparency to the list of > * supported image types. > */ > > File: PNGImageReader.java > Line(s): 1290, 1493, 1596, 1619 > . The lines mentioned above check whether metadata has specific transparent color using- > metadata.tRNS_present && > (metadata.tRNS_colorType == PNG_COLOR_RGB || > metadata.tRNS_colorType == PNG_COLOR_GRAY) > > . The above check is not only redundant but also metadata specific. > . We could move the code to a common method in PNGMetadata- > boolean hasTransparentColor() { > return tRNS_present > && (tRNS_colorType == PNG_COLOR_RGB > || tRNS_colorType == PNG_COLOR_GRAY); > } > . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. > . As per the specification, tRNS values depend on the image's color type. > . This will reduce the complex check from- > if (theImage.getSampleModel().getNumBands() == > inputBandsForColorType[colorType] + 1 && > metadata.tRNS_present && > (metadata.tRNS_colorType == PNG_COLOR_RGB || > metadata.tRNS_colorType == PNG_COLOR_GRAY)) > { > to- > if (metadata.hasTransparentColor() > && (theImage.getSampleModel().getNumBands() == > inputBandsForColorType[colorType] + 1)) { > > File: PNGImageReader.java > Line: 1329, 1342 > . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. > . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. > int[] temp = new int[inputBands + 1]; > int opaque = (bitDepth < 16) ? 255 : 65535; > Arrays.fill(temp, opaque); > . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. > > File: PNGImageReader.java > All modified Lines: > . The opening braces '{' can appear in the new line. Some engineers do follow this. > . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. > > Test File: ReadPngGrayImageWithTRNSChunk.java and > ReadPngRGBImageWithTRNSChunk.java > . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. > . The call to directory(while is a File).delete() is not required in my view. Verify this once. > . Dispose the writer after the write operation is complete. > > Thank you > Have a good day > > Prahalad N. > > -----Original Message----- > From: Jayathirth D V > Sent: Thursday, April 05, 2018 3:26 PM > To: Prahalad Kumar Narayanan; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello Prahalad, > > Thank you for the inputs. > > I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. > I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). > isTransparentPixelPresent() code is removed and we are using available tRNS properties. > > I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ > > Thanks, > Jay > > -----Original Message----- > From: Prahalad Kumar Narayanan > Sent: Monday, April 02, 2018 12:03 PM > To: Krishna Addepalli; Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello Jay > > Good day to you. > > I looked into the latest code changes. > Please find my review observation & suggestions herewith. > > My understanding of problem statement: > . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. > . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. > > Appropriate Changes: > > File: PNGImageReader.java, > Method: Iterator getImageTypes > Line: 1633 > . This method is internally invoked while creating BufferedImage for destination at Line 1409: > theImage = getDestination(param, > getImageTypes(0), > width, > height); > . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. > > File: PNGImageReader.java > Method: readMetadata > Line: 731 > . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. > . The chunk's information will be needed. > > Other Observation & Suggestions: > > File: PNGImageReader.java, > Method: decodePass > Line: (1088 - 1112), (1277-1327) > . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. > . The changes are not required in my view. Reasons are- > . passRow corresponds to the data from input image source. > . imgRas corresponds to the destination buffered image. > . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. > imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. > . However, the proposed changes modify how we interpret the source through passRow. > . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. > . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. > > File: PNGImageReader.java, > Method: isTransparentPixelPresent > Line: 1545 > . The logic of this method considers both input image source and destination bands to decide whether transparency is available. > . In my view, The method should consider only the alpha in input image source and not the destination. > . Here are code points where the method is invoked > a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. > b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. > c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) > d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. > . Each of the locations except (c) pertain to image source and not the destination. > . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). > > . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. > . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" > . Just curious to know if there 's any basis for this observation ? > . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. > > Line: 1555 > . Please use tRNS_colorType together with tRNS_present flag. > > File: PNGImageReader.java, > Method: readMetadata > Line: 701 > Rephrase From: > * Optimization: We can skip reading metadata if ignoreMetadata > * flag is set and colorType is not PNG_COLOR_PALETTE. But we need > * to parse only the tRNS chunk even in the case where IHDR colortype > * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent > * pixel information for PNG_COLOR_RGB while storing the pixel data > * in decodePass(). > To: > * Optimization: We can skip reading metadata if ignoreMetadata > * flag is set and colorType is not PNG_COLOR_PALETTE. However, > * we parse tRNS chunk to retrieve the transparent color from the > * metadata irrespective of the colorType. Doing so, helps > * PNGImageReader to appropriately identify and set transparent > * pixels in the decoded image. > > File: PNGMetadata.java > Line: 271 > . Reset the tRNS_colorType to -1 in the reset() method. > . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. > . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. > . When the same ImageReader is used to read multiple PNG images, this could pose a problem. > > Thank you > Have a good day > > Prahalad N. > > > ----- Original Message ----- > From: Krishna Addepalli > Sent: Monday, April 02, 2018 11:40 AM > To: Jayathirth D V; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. > Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. > > Thanks, > Krishna > > From: Jayathirth D V > Sent: Monday, April 2, 2018 11:33 AM > To: Krishna Addepalli ; 2d-dev > <2d-dev at openjdk.java.net> > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hi Krishna, > > The constant values for different color types is : > static final int PNG_COLOR_GRAY = 0; > static final int PNG_COLOR_RGB = 2; > static final int PNG_COLOR_PALETTE = 3; > static final int PNG_COLOR_GRAY_ALPHA = 4; > static final int PNG_COLOR_RGB_ALPHA = 6; > > Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. > By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. > > Thanks, > Jay > > From: Krishna Addepalli > Sent: Monday, April 02, 2018 9:56 AM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hi Jay, > > The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? > > Thanks, > Krishna > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 1:43 PM > To: Krishna Addepalli ; 2d-dev > <2d-dev at openjdk.java.net> > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hi Krishna, > > Thanks for providing the inputs. > > 1. I suggest to rename considerTransparentPixel as isAlphaPresent. > As discussed I have added new name as isTransparentPixelPresent() > > 2. You can refactor the function body as below: > Return ((destinationBands == null || > destinationBands.length == 4) && > metadata.tRNS_colorType == PNG_COLOR_RGB); > > Changes are made. > > 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. > > Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. > Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. > > 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: > for (int i = 0; i < passWidth; i++) { > byteData[destidx] = curr[srcidx]; > byteData[destidx + 1] = curr[srcidx + 1]; > byteData[destidx + 2] = curr[srcidx + 2]; > if (curr[srcidx] == (byte)metadata.tRNS_red && > curr[srcidx + 1] == (byte)metadata.tRNS_green && > curr[srcidx + 2] == (byte)metadata.tRNS_blue) > { > byteData[destidx + 3] = (byte)0; > } else { > byteData[destidx + 3] = (byte)255; > } > srcidx += 3; > destidx += 4; > } > Same thing can be done for the loop that executes for 16bit pixel data. > > Changes are made. > > > Please find updated webrev for review : > http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ > > Thanks, > Jay > > From: Krishna Addepalli > Sent: Wednesday, March 28, 2018 11:52 AM > To: Jayathirth D V; 2d-dev > Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hi Jay, > > I have some points as below: > 1. I suggest to rename considerTransparentPixel as isAlphaPresent. > 2. You can refactor the function body as below: > Return ((destinationBands == null || > destinationBands.length == 4) && > metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. > 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: > for (int i = 0; i < passWidth; i++) { > byteData[destidx] = curr[srcidx]; > byteData[destidx + 1] = curr[srcidx + 1]; > byteData[destidx + 2] = curr[srcidx + 2]; > if (curr[srcidx] == (byte)metadata.tRNS_red && > curr[srcidx + 1] == (byte)metadata.tRNS_green && > curr[srcidx + 2] == (byte)metadata.tRNS_blue) > { > byteData[destidx + 3] = (byte)0; > } else { > byteData[destidx + 3] = (byte)255; > } > srcidx += 3; > destidx += 4; > } > Same thing can be done for the loop that executes for 16bit pixel data. > > > I haven't yet checked the test cases. > > Thanks, > Krishna > > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 9:52 AM > To: 2d-dev <2d-dev at openjdk.java.net> > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello All, > > I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ > > Thanks, > Jay > > From: Jayathirth D V > Sent: Wednesday, March 28, 2018 8:28 AM > To: 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader > ignores tRNS chunk while reading non-indexed RGB images > > Hello All, > > I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. > > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ > > Thanks, > Jay > > From: Jayathirth D V > Sent: Tuesday, March 27, 2018 6:51 PM > To: 2d-dev > Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores > tRNS chunk while reading non-indexed RGB images > > Hello All, > > Please review the following solution in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 > Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ > > Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. > > Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. > > Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. > > Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. > > One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. > > Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. > > Thanks, > Jay From jayathirth.d.v at oracle.com Fri Apr 13 08:53:52 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 13 Apr 2018 01:53:52 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: References: Message-ID: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> Hi Phil, Thanks for your inputs. I have modified the test case to use ByteArrayOutput/InputStream. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6574555/webrev.01/ Regards, Jay From: Phil Race Sent: Wednesday, April 11, 2018 10:40 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk The fix seems fine but like the other review I wonder if the test can use a bytearrayoutputstream instead of writing to a file. -phil. On 04/11/2018 03:51 AM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6574555/webrev.00/"http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ Issue: PNGImageWriter. write_bKGD() function sets incorrect R, G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). Solution: Assign values to all channels of RGB as they are present in Metadata instead of using only bKGD red value. Note : Our default metadata doesn't set any bKGD chunk but if user specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B values and if r == g == b then we store bKGD chunk as of type PNG_COLOR_GRAY. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Apr 13 17:20:59 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Apr 2018 10:20:59 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: Message-ID: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> I suppose this potentially helps the concurrency of the build ? I can't think of why this would be a problem now there is no compile-time linking involved and it seems Linux was already fine without this, but a jdk-submit would be prudent .. -phil. On 04/13/2018 09:22 AM, Volker Simonis wrote: > Hi Erik, > > thanks for looking at the patch and good catch! You're right that the > dependency can now be removed. Here's the new webrev: > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > Regards, > Volker > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson wrote: >> Hello Volker, >> >> The change looks good, but now that we no longer link against >> libawt_headless, we should also remove the make dependency a few lines down. >> (Should have been done already for Solaris.) >> >> /Erik >> >> >> >> On 2018-04-13 06:28, Volker Simonis wrote: >>> Hi, >>> >>> can I please have a review for this tiny AIX cleanup: >>> >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >>> https://bugs.openjdk.java.net/browse/JDK-8201524 >>> >>> This is a follow up change of JDK-8196516 which discovered that on AIX >>> libfontmanager is always linked against libawt_headless at build time. >>> If we are running in a headfull environment, libfontmanager will >>> dynamically load libawt_xawt which is not good because libawt_headless >>> and libawt_xawt define some common symbols. If we're running in a >>> headless environment, libawt_headless may be loaded a second time (at >>> least on Linux/Solaris) which isn't good either. >>> >>> Both of these scenarios haven't caused any problems on AIX yet, but I >>> think it's good to cleanup the AIX implementation as well and don't >>> link libfontmanager against libawt_headless anymore. In order to >>> achieve this, we have to allow unresolved symbols during the linking >>> of libfontmanager. This can be easily achieved by adding the additions >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >>> for AIX because options which come later on the command line take >>> precedence >>> over earlier ones. >>> >>> Thank you and best regards, >>> Volker >> From erik.joelsson at oracle.com Fri Apr 13 18:31:15 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 11:31:15 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: <77be34a6-352e-7ded-7be3-a6e0b02d9a74@oracle.com> Yes, we don't want unneeded dependencies declared as it both potentially slows down the build (though this removal will not have any measurable impact) as well as confuses humans trying to make sense of the makefiles. This removal should be fine as we don't link to libawt_xawt on any platform anymore. Linking is the only reason we have those dependencies. /Erik On 2018-04-13 10:20, Phil Race wrote: > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: >> Hi Erik, >> >> thanks for looking at the patch and good catch! You're right that the >> dependency can now be removed. Here's the new webrev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 >> >> Regards, >> Volker >> >> On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson >> wrote: >>> Hello Volker, >>> >>> The change looks good, but now that we no longer link against >>> libawt_headless, we should also remove the make dependency a few >>> lines down. >>> (Should have been done already for Solaris.) >>> >>> /Erik >>> >>> >>> >>> On 2018-04-13 06:28, Volker Simonis wrote: >>>> Hi, >>>> >>>> can I please have a review for this tiny AIX cleanup: >>>> >>>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ >>>> https://bugs.openjdk.java.net/browse/JDK-8201524 >>>> >>>> This is a follow up change of JDK-8196516 which discovered that on AIX >>>> libfontmanager is always linked against libawt_headless at build time. >>>> If we are running in a headfull environment, libfontmanager will >>>> dynamically load libawt_xawt which is not good because libawt_headless >>>> and libawt_xawt define some common symbols. If we're running in a >>>> headless environment, libawt_headless may be loaded a second time (at >>>> least on Linux/Solaris) which isn't good either. >>>> >>>> Both of these scenarios haven't caused any problems on AIX yet, but I >>>> think it's good to cleanup the AIX implementation as well and don't >>>> link libfontmanager against libawt_headless anymore. In order to >>>> achieve this, we have to allow unresolved symbols during the linking >>>> of libfontmanager. This can be easily achieved by adding the additions >>>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine >>>> for AIX because options which come later on the command line take >>>> precedence >>>> over earlier ones. >>>> >>>> Thank you and best regards, >>>> Volker >>> > From volker.simonis at gmail.com Fri Apr 13 19:44:36 2018 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 13 Apr 2018 19:44:36 +0000 Subject: [OpenJDK 2D-Dev] RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: Phil Race schrieb am Fr. 13. Apr. 2018 um 19:21: > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > I did start Solaris and AIX builds before I left the office. I can certainly also submit a job to JDK-submit, but at least hs-submit wasn?t working at all (i.e. didn?t return any results). > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a few lines > down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered that on AIX > >>> libfontmanager is always linked against libawt_headless at build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX yet, but I > >>> think it's good to cleanup the AIX implementation as well and don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the linking > >>> of libfontmanager. This can be easily achieved by adding the additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Fri Apr 13 19:53:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 13 Apr 2018 12:53:59 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: On 2018-04-13 12:44, Volker Simonis wrote: > > Phil Race > > schrieb am Fr. 13. Apr. 2018 um 19:21: > > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > > I did start Solaris and AIX builds before I left the office. I can > certainly also submit a job to JDK-submit, but at least hs-submit > wasn?t working at all (i.e. didn?t return any results). > hs-submit is disabled since the merge of jdk/hs to jdk/jdk. /Erik > > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right > that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a > few lines down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered > that on AIX > >>> libfontmanager is always linked against libawt_headless at > build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because > libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second > time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX > yet, but I > >>> think it's good to cleanup the AIX implementation as well and > don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the > linking > >>> of libfontmanager. This can be easily achieved by adding the > additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This > works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Apr 13 19:59:49 2018 From: philip.race at oracle.com (Phil Race) Date: Fri, 13 Apr 2018 12:59:49 -0700 Subject: [OpenJDK 2D-Dev] RFR(XS): 8201524: [AIX] Don't link libfontmanager against libawt_headless In-Reply-To: References: <958a9179-c3f5-fd03-4679-883e88dd42f2@oracle.com> Message-ID: <2e82d272-3cda-9786-f5bf-14dd188fc2ec@oracle.com> On 04/13/2018 12:44 PM, Volker Simonis wrote: > > Phil Race > > schrieb am Fr. 13. Apr. 2018 um 19:21: > > > I suppose this potentially helps the concurrency of the build ? > I can't think of why this would be a problem now there is no > compile-time linking > involved and it seems Linux was already fine without this, > but a jdk-submit would be prudent .. > > > I did start Solaris and AIX builds before I left the office. That should be sufficient ... -phil. > I can certainly also submit a job to JDK-submit, but at least > hs-submit wasn?t working at all (i.e. didn?t return any results). > > > -phil. > > On 04/13/2018 09:22 AM, Volker Simonis wrote: > > Hi Erik, > > > > thanks for looking at the patch and good catch! You're right > that the > > dependency can now be removed. Here's the new webrev: > > > > http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524.v1 > > > > > Regards, > > Volker > > > > On Fri, Apr 13, 2018 at 6:00 PM, Erik Joelsson > > wrote: > >> Hello Volker, > >> > >> The change looks good, but now that we no longer link against > >> libawt_headless, we should also remove the make dependency a > few lines down. > >> (Should have been done already for Solaris.) > >> > >> /Erik > >> > >> > >> > >> On 2018-04-13 06:28, Volker Simonis wrote: > >>> Hi, > >>> > >>> can I please have a review for this tiny AIX cleanup: > >>> > >>> http://cr.openjdk.java.net/~simonis/webrevs/2018/8201524/ > > >>> https://bugs.openjdk.java.net/browse/JDK-8201524 > >>> > >>> This is a follow up change of JDK-8196516 which discovered > that on AIX > >>> libfontmanager is always linked against libawt_headless at > build time. > >>> If we are running in a headfull environment, libfontmanager will > >>> dynamically load libawt_xawt which is not good because > libawt_headless > >>> and libawt_xawt define some common symbols. If we're running in a > >>> headless environment, libawt_headless may be loaded a second > time (at > >>> least on Linux/Solaris) which isn't good either. > >>> > >>> Both of these scenarios haven't caused any problems on AIX > yet, but I > >>> think it's good to cleanup the AIX implementation as well and > don't > >>> link libfontmanager against libawt_headless anymore. In order to > >>> achieve this, we have to allow unresolved symbols during the > linking > >>> of libfontmanager. This can be easily achieved by adding the > additions > >>> linker flag "-Wl$(COMMA)-berok" through LDFLAGS_aix. This > works fine > >>> for AIX because options which come later on the command line take > >>> precedence > >>> over earlier ones. > >>> > >>> Thank you and best regards, > >>> Volker > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Apr 13 20:06:07 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Apr 2018 13:06:07 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM In-Reply-To: <975dff93-d8fd-e245-eebe-059281c7bda9@oracle.com> References: <8adda526-8027-0cc0-c290-ccf94a1bbdf6@oracle.com> <975dff93-d8fd-e245-eebe-059281c7bda9@oracle.com> Message-ID: Looks fine. On 12/04/2018 15:15, Alexey Ivanov wrote: > Hi Sergey, > > Thank you for your review. > > Please take a look at the updated webrev: > http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.01/ > > On 12/04/2018 22:33, Sergey Bylokhov wrote: >> Hi, Alexey. >> Since the test requires 1g of memory, should we use this tag?: >> ?* @requires os.maxMemory >= 1g >> Otherwise the test may fail on start if amount of memory is not >> sufficient. > > It makes sense to add it so that the test is skipped if there's not > enough of memory. > However, I think the actual requirement is >= 2G as it needs 1G for Java > heap and it needs native memory for images and for other purposes. > > The test exhausts the available native memory to make malloc fail. The > amount of used memory reaches close to 2G before it fails. > > > Regards, > Alexey > >> >> On 12/04/2018 08:25, Alexey Ivanov wrote: >>> Hi, >>> >>> Please review the fix for jdk11: >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8201433 >>> webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk11/webrev.00/ >>> >>> >>> When the JVM is run with limited amount of memory, initCubemap >>> function called from BufImg_SetupICM can return NULL. It can lead to >>> a crash. It usually happens when native memory is exhausted and >>> malloc fails. In this state, JVM itself is not stable. >>> >>> Adding NULL-check can prevent the crash in this particular place. >>> However, if the app continues, since native memory is exhausted and >>> malloc fails, JVM can still crash in another place. >>> >>> >>> Thank you in advance. >>> >>> Regards, >>> Alexey -- Best regards, Sergey. From adam.farley at uk.ibm.com Mon Apr 16 10:58:40 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Mon, 16 Apr 2018 11:58:40 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c Message-ID: I also advocate the source code fix, as Make isn't meant to use the sort of logic required to properly analyse the toolchain version string. e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and Make doesn't seem to do substring stuff unless you mess around with shells. Plus, as people have said, it's better to solve problem x (or work around a specific instance of x) than to ignore the exception, even if the ignoring code is toolchain- specific. - Adam Farley > On 2018-03-27 18:44, Phil Race wrote: > >> As I said I prefer the make file change, since this is a change to an upstream library. > > Newtons fourth law: For every reviewer, there's an equal and opposite reviewer. :) > > Here I am, advocating a source code fix. As Thomas says, the compiler complaint seems reasonable, and disabling it might cause us to miss other future errors. > > Why can't we push the source code fix, and also submit it upstream? > > /Magnus > > > I've looked at jpeg-9c and it still looks identical to what we have in 6b, so this code > seems to have stood the test of time. I'm also unclear why the compiler would > complain about that and not the one a few lines later > > > 819 while (bits[i] == 0) /* find largest codelength still in use */ > 820 i--; > > A push to jchuff.c will get blown away if/when we upgrade. > A tool-chain specific fix in the makefile with an appropriate comment is more targeted. > > > -phil. > > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > Hi all, > > > just a friendly reminder. I would like to push this tiny fix because tripping over this on our linux s390x builds is annoying (yes, we can maintain patch queues, but this is a constant error source). > > > I will wait for 24 more hours until a reaction. If no serious objections are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph langer are both Reviewers). > > > Thanks! Thomas > > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe wrote: > > Hi all, > > > may I please have another review for this really trivial change. It fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix this. > > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > This was contributed by Adam Farley at IBM. > > > I already reviewed this. I also test-built on zlinux and it works. > > > Thanks, Thomas > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.ihse.bursie at oracle.com Mon Apr 16 11:50:22 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Apr 2018 13:50:22 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: <2682b47d-7d36-2fcd-7f79-928217925c13@oracle.com> On 2018-04-16 12:58, Adam Farley8 wrote: > I also advocate the source code fix, as Make isn't meant to use the > sort of logic required > to properly analyse the toolchain version string. > > e.g. An "eq" match on 4.8.5 doesn't protect the user who is using > 4.8.6, and Make doesn't > seem to do substring stuff unless you mess around with shells. > > Plus, as people have said, it's better to solve problem x (or work > around a specific > instance of x) than to ignore the exception, even if the ignoring code > is toolchain- > specific. > > - Adam Farley > > > On 2018-03-27 18:44, Phil Race wrote: > > > >> As I said I prefer the make file change, since this is a change to an > upstream library. > > > > Newtons fourth law: For every reviewer, there's an equal and opposite > reviewer. :) > > > > Here I am, advocating a source code fix. As Thomas says, the compiler > complaint seems reasonable, and disabling it might cause us to miss > other future errors. > > > > Why can't we push the source code fix, and also submit it upstream? > > > > /Magnus > > > > > > I've looked at jpeg-9c and it still looks identical to what we have in 6b, > so this code > > seems to have stood the test of time. I'm also unclear why the compiler would > > complain about that and not the one a few lines later > > > > > > ?819 ? while (bits[i] == 0) ? ? ? ? ?/* find largest codelength still in > use */ > > ?820 ? ? i--; > > > > A push to jchuff.c will get blown away if/when we upgrade. > > A tool-chain specific fix in the makefile with an appropriate comment > is more targeted. Phil, Returning to this. While I understand your reluctance to patch upstream code, let me point out that we have not updated libjpeg a single time since the JDK was open sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page on libjpeg, and this is the latest "uncontroversial" version of the source. Versions 7 and up have proprietary extensions, which in turn has resulted in multiple forks of libjpeg. As it stands, it seems unlikely that we will ever replace libjpeg 6b with a simple upgrade from upstream. I therefore maintain my position that a source code fix would be the best way forward here. /Magnus > > > > > > > -phil. > > > > > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > > Hi all, > > > > > > just a friendly reminder. I would like to push this tiny fix because > tripping over this on our linux s390x builds is annoying (yes, we can > maintain patch queues, but this is a constant error source). > > > > > > I will wait for 24 more hours until a reaction. If no serious objections are > forcoming, I want to push it (tier1 tests ran thru, and me and > Christoph langer are both Reviewers). > > > > > > Thanks! Thomas > > > > > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe wrote: > > > > Hi all, > > > > > > may I please have another review for this really trivial change. It fixes a > gcc warning on s390 and ppc. Also, it is probably a good idea to fix > this. > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > > > > This was contributed by Adam Farley at IBM. > > > > > > I already reviewed this. I also test-built on zlinux and it works. > > > > > > Thanks, Thomas > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexey.ivanov at oracle.com Mon Apr 16 12:59:23 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 16 Apr 2018 13:59:23 +0100 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: Hi Matthias, Phil, The build of 32 bit Windows is broken because of mlib_image.dll. As JNICALL modifier has been added to function declarations, they're exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. The functions in this library are looked up by their name [1] and therefore none can be found. If you run tests in test/jdk/java/awt/image, for example test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail because ImagingLib is not available. I'm working on a patch to fix it. Regards, Alexey [1] http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60 On 13/04/2018 06:48, Baesken, Matthias wrote: > Hi Phil/Alexey, thanks for adding the other lists . > >> Is this the current version of the change : http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? > Yes. > > Best regards, Matthias > > >> -----Original Message----- >> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >> Sent: Donnerstag, 12. April 2018 23:53 >> To: Phil Race ; Baesken, Matthias >> ; Alan Bateman ; >> Magnus Ihse Bursie >> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, >> Martin ; 2d-dev <2d-dev at openjdk.java.net>; >> hotspot-dev >> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in function >> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >> some places in function declarations/implementations >> >> >> On 12/04/2018 21:42, Phil Race wrote: >>> How can JNIEXPORT be different between 32 bit & 64 bit ? >>> I'm sure you saw compilation errors but I don't get why it failed for >>> 32 only. >>> >>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that doesn't >>> explain why the 32 bit compiler would complain about inconsistent >>> application >>> of __declspec(dllexport) - ie JNIEXPORT. >>> >>> Or is that part (adding JNIEXPORT) pure clean up and the compilation >>> errors were all down to JNICALL ? >> Adding missing JNIEXPORT is for cleanup only. >> >> The compiler complained about mismatched JNICALL / non-JNICALL >> declarations as the macro changes calling convention from the default >> __cdecl? to __stdcall on 32 bit Windows. >> >> Another issue is that __stdcall decorates the functions: prefixes with >> underscore and postfixes with @ + size of parameters. Because of the >> decorations, classLoader.cpp can't lookup the required functions by name >> from zip.dll and jimage.dll. The functions are exported but with >> different name. >> >> I hope this information adds more details to the picture. >> >>> I was a bit puzzled at the removals I saw here : >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto >> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html >>> .. I needed to look at the whole file to realise that you were >>> removing a duplicate >>> declaration. >> That was tricky. I could have been mentioned in the review. >> >> >> Regards, >> Alexey >> >>> -phil. >>> >>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >>>> Hi? Alan , this is the up to date webrev . >>>> However we want to add?? Alexey?? Ivanov? as additional? author . >>>> >>>>> As I read it, this changes the calling convention of these functions on >>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>> __stdcall is ignored) or other platforms, is that correct? >>>>> >>>> The? change adds? JNIEXPORT?? at some places? where it is? ben >>>> forgotten , for example : >>>> >>>> >> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >>>> >>>> This might have? potential? impact? on other platforms?? (fixes the >>>> mismatches) . >>>> >>>> Best regards, Matthias >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>>> Sent: Donnerstag, 12. April 2018 12:54 >>>>> To: Baesken, Matthias ; Magnus Ihse Bursie >>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin ; core-libs-dev at openjdk.java.net >>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>> function >>>>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>>>> some places in function declarations/implementations >>>>> >>>>> Adding core-libs-dev as this is change code in libjava, libzip, >>>>> libjimage, ... >>>>> >>>>> Can you confirm that this is the up to date webrev: >>>>> ???? http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>> >>>>> As I read it, this changes the calling convention of these functions on >>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>> __stdcall is ignored) or other platforms, is that correct? >>>>> >>>>> -Alan >>>>> >>>>> >>>>> From magnus.ihse.bursie at oracle.com Mon Apr 16 13:03:12 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 16 Apr 2018 15:03:12 +0200 Subject: [OpenJDK 2D-Dev] 8201226 missing JNIEXPORT / JNICALL at some places in function declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at some places in function declarations/implementations In-Reply-To: References: <9bae15f406ed4e029233415e6a8032b8@sap.com> <81feebd9-b3b5-35c2-8c12-d63a0ad42200@oracle.com> <7c5e68c2a023490e96ce6452fbda1700@sap.com> <9fff2e7e-06ac-54c1-8f66-33bff34ea621@oracle.com> Message-ID: On 2018-04-16 14:59, Alexey Ivanov wrote: > Hi Matthias, Phil, > > The build of 32 bit Windows is broken because of mlib_image.dll. As > JNICALL modifier has been added to function declarations, they're > exported with a decorated name, for example _j2d_mlib_ImageCreate at 16. > The functions in this library are looked up by their name [1] and > therefore none can be found. You should most likely just be able to remove the JNICALL modifiers for libmlib_image. /Magnus > > If you run tests in test/jdk/java/awt/image, for example > test/jdk/java/awt/image/mlib/MlibOpsTest.java, some of them fail > because ImagingLib is not available. > > I'm working on a patch to fix it. > > > Regards, > Alexey > > [1] > http://hg.openjdk.java.net/jdk/jdk/file/bc1c7e41e285/src/java.desktop/windows/native/libawt/windows/awt_Mlib.cpp#l60 > > On 13/04/2018 06:48, Baesken, Matthias wrote: >> Hi Phil/Alexey,? thanks for? adding the other lists . >> >>> Is this the current version of the change : >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ ? >> Yes. >> >> Best regards, Matthias >> >> >>> -----Original Message----- >>> From: Alexey Ivanov [mailto:alexey.ivanov at oracle.com] >>> Sent: Donnerstag, 12. April 2018 23:53 >>> To: Phil Race ; Baesken, Matthias >>> ; Alan Bateman ; >>> Magnus Ihse Bursie >>> Cc: build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; Doerr, >>> Martin ; 2d-dev <2d-dev at openjdk.java.net>; >>> hotspot-dev >>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>> function >>> declarations/implementations - was : RE: missing JNIEXPORT / JNICALL at >>> some places in function declarations/implementations >>> >>> >>> On 12/04/2018 21:42, Phil Race wrote: >>>> How can JNIEXPORT be different between 32 bit & 64 bit ? >>>> I'm sure you saw compilation errors but I don't get why it failed for >>>> 32 only. >>>> >>>> JNICALL (_stdcall) may be unnecessary on 64 bit Windows but that >>>> doesn't >>>> explain why the 32 bit compiler would complain about inconsistent >>>> application >>>> of __declspec(dllexport) - ie JNIEXPORT. >>>> >>>> Or is that part (adding JNIEXPORT) pure clean up and the compilation >>>> errors were all down to JNICALL ? >>> Adding missing JNIEXPORT is for cleanup only. >>> >>> The compiler complained about mismatched JNICALL / non-JNICALL >>> declarations as the macro changes calling convention from the default >>> __cdecl? to __stdcall on 32 bit Windows. >>> >>> Another issue is that __stdcall decorates the functions: prefixes with >>> underscore and postfixes with @ + size of parameters. Because of the >>> decorations, classLoader.cpp can't lookup the required functions by >>> name >>> from zip.dll and jimage.dll. The functions are exported but with >>> different name. >>> >>> I hope this information adds more details to the picture. >>> >>>> I was a bit puzzled at the removals I saw here : >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.deskto >>> p/share/native/libsplashscreen/splashscreen_impl.h.udiff.html >>>> .. I needed to look at the whole file to realise that you were >>>> removing a duplicate >>>> declaration. >>> That was tricky. I could have been mentioned in the review. >>> >>> >>> Regards, >>> Alexey >>> >>>> -phil. >>>> >>>> On 04/12/2018 04:04 AM, Baesken, Matthias wrote: >>>>> Hi? Alan , this is the up to date webrev . >>>>> However we want to add?? Alexey?? Ivanov? as additional author . >>>>> >>>>>> As I read it, this changes the calling convention of these >>>>>> functions on >>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>>> __stdcall is ignored) or other platforms, is that correct? >>>>>> >>>>> The? change adds? JNIEXPORT?? at some places? where it is ben >>>>> forgotten , for example : >>>>> >>>>> >>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/src/java.desktop/share/native/libmlib_image/mlib_c_ImageLookUp.c.udiff.html >>> >>>>> >>>>> This might have? potential? impact? on other platforms (fixes the >>>>> mismatches) . >>>>> >>>>> Best regards, Matthias >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Alan Bateman [mailto:Alan.Bateman at oracle.com] >>>>>> Sent: Donnerstag, 12. April 2018 12:54 >>>>>> To: Baesken, Matthias ; Magnus Ihse >>>>>> Bursie >>>>>> Cc: build-dev at openjdk.java.net; Doerr, Martin >>>>>> ; core-libs-dev at openjdk.java.net >>>>>> Subject: Re: 8201226 missing JNIEXPORT / JNICALL at some places in >>>>>> function >>>>>> declarations/implementations - was : RE: missing JNIEXPORT / >>>>>> JNICALL at >>>>>> some places in function declarations/implementations >>>>>> >>>>>> Adding core-libs-dev as this is change code in libjava, libzip, >>>>>> libjimage, ... >>>>>> >>>>>> Can you confirm that this is the up to date webrev: >>>>>> http://cr.openjdk.java.net/~mbaesken/webrevs/8201226.2/ >>>>>> >>>>>> As I read it, this changes the calling convention of these >>>>>> functions on >>>>>> 32-bit Windows but it will have no impact on 64-bit Windows (as >>>>>> __stdcall is ignored) or other platforms, is that correct? >>>>>> >>>>>> -Alan >>>>>> >>>>>> >>>>>> > From prahalad.kumar.narayanan at oracle.com Tue Apr 17 06:20:09 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Mon, 16 Apr 2018 23:20:09 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> References: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> Message-ID: <8f34e23e-b5e8-4436-8f62-2ff859cef583@default> Hello Jay The changes are fine. Just a minor observation: The image reader should be disposed in the test case. Thank you Have a good day Prahalad N. From: Jayathirth D V Sent: Friday, April 13, 2018 2:24 PM To: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hi Phil, Thanks for your inputs. I have modified the test case to use ByteArrayOutput/InputStream. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6574555/webrev.01/ Regards, Jay From: Phil Race Sent: Wednesday, April 11, 2018 10:40 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk The fix seems fine but like the other review I wonder if the test can use a bytearrayoutputstream instead of writing to a file. -phil. On 04/11/2018 03:51 AM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6574555/webrev.00/"http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ Issue: PNGImageWriter. write_bKGD() function sets incorrect R, G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). Solution: Assign values to all channels of RGB as they are present in Metadata instead of using only bKGD red value. Note : Our default metadata doesn't set any bKGD chunk but if user specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B values and if r == g == b then we store bKGD chunk as of type PNG_COLOR_GRAY. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Apr 17 08:53:28 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 17 Apr 2018 01:53:28 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: <8f34e23e-b5e8-4436-8f62-2ff859cef583@default> References: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> <8f34e23e-b5e8-4436-8f62-2ff859cef583@default> Message-ID: <8b49fe59-0122-47d9-ac63-7b3b202eb269@default> Hi Prahalad, Thanks for the review. I have updated the test case to dispose the image reader. Please find updated webrev: http://cr.openjdk.java.net/~jdv/6574555/webrev.02/ Regards, Jay From: Prahalad Kumar Narayanan Sent: Tuesday, April 17, 2018 11:50 AM To: Jayathirth D V; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hello Jay The changes are fine. Just a minor observation: The image reader should be disposed in the test case. Thank you Have a good day Prahalad N. From: Jayathirth D V Sent: Friday, April 13, 2018 2:24 PM To: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hi Phil, Thanks for your inputs. I have modified the test case to use ByteArrayOutput/InputStream. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6574555/webrev.01/ Regards, Jay From: Phil Race Sent: Wednesday, April 11, 2018 10:40 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk The fix seems fine but like the other review I wonder if the test can use a bytearrayoutputstream instead of writing to a file. -phil. On 04/11/2018 03:51 AM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6574555/webrev.00/"http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ Issue: PNGImageWriter. write_bKGD() function sets incorrect R, G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). Solution: Assign values to all channels of RGB as they are present in Metadata instead of using only bKGD red value. Note : Our default metadata doesn't set any bKGD chunk but if user specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B values and if r == g == b then we store bKGD chunk as of type PNG_COLOR_GRAY. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prahalad.kumar.narayanan at oracle.com Tue Apr 17 09:27:44 2018 From: prahalad.kumar.narayanan at oracle.com (Prahalad Kumar Narayanan) Date: Tue, 17 Apr 2018 02:27:44 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: <8b49fe59-0122-47d9-ac63-7b3b202eb269@default> References: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> <8f34e23e-b5e8-4436-8f62-2ff859cef583@default> <8b49fe59-0122-47d9-ac63-7b3b202eb269@default> Message-ID: <0d5098be-be61-4c3c-8d59-850c002f5b61@default> Hello Jay Changes are good. Thanks Have a good day Prahalad N. From: Jayathirth D V Sent: Tuesday, April 17, 2018 2:23 PM To: Prahalad Kumar Narayanan; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hi Prahalad, Thanks for the review. I have updated the test case to dispose the image reader. Please find updated webrev: http://cr.openjdk.java.net/~jdv/6574555/webrev.02/ Regards, Jay From: Prahalad Kumar Narayanan Sent: Tuesday, April 17, 2018 11:50 AM To: Jayathirth D V; Philip Race; 2d-dev Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hello Jay The changes are fine. Just a minor observation: The image reader should be disposed in the test case. Thank you Have a good day Prahalad N. From: Jayathirth D V Sent: Friday, April 13, 2018 2:24 PM To: Philip Race; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk Hi Phil, Thanks for your inputs. I have modified the test case to use ByteArrayOutput/InputStream. Please find updated webrev for review: http://cr.openjdk.java.net/~jdv/6574555/webrev.01/ Regards, Jay From: Phil Race Sent: Wednesday, April 11, 2018 10:40 PM To: Jayathirth D V; 2d-dev Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk The fix seems fine but like the other review I wonder if the test can use a bytearrayoutputstream instead of writing to a file. -phil. On 04/11/2018 03:51 AM, Jayathirth D V wrote: Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/6574555/webrev.00/"http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ Issue: PNGImageWriter. write_bKGD() function sets incorrect R, G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). Solution: Assign values to all channels of RGB as they are present in Metadata instead of using only bKGD red value. Note : Our default metadata doesn't set any bKGD chunk but if user specifies bKGD chunk and uses mergeTree() then we check bKGD R, G, B values and if r == g == b then we store bKGD chunk as of type PNG_COLOR_GRAY. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Tue Apr 17 10:04:04 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 17 Apr 2018 03:04:04 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Message-ID: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-5109146 Webrev : http://cr.openjdk.java.net/~jdv/5109146/webrev.00/ Issue: PNGMetadata.mergeStandardTree() function doesn't set proper bKGD colortype. Solution: When bKGD R, G, B values are unique we need to store appropriate bKGD colortype in metadata. Note : Test case which is present as part of review in JDK-6574555 is only updated to handle regression scenario for this bug also. Regression scenario between this bug and JDK-6574555 differ only in what type(native/standard) metadata we use to merge bKGD RGB values. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Tue Apr 17 15:30:36 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Apr 2018 08:30:36 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images In-Reply-To: <3f81e593-4f58-4b0e-a52c-ad05d92299dd@default> References: <2404b9b8-9394-441c-a2c9-9c7f2daebd5c@default> <40269d9d-9bec-4b2e-9e6b-7c38628198a7@default> <221f5050-46f4-4018-bc9b-54a8621d3b05@default> <145db2fc-516f-4602-be90-210985690f22@default> <3ee71509-4d73-462d-85ca-9cf842ea71ae@default> <985951de-1413-4744-901d-cf3ea1cc88c7@default> <4f048f06-8796-49e6-b127-87fa64d03e51@default> <8c37095e-e4d9-4e4e-ba84-71f7727e79fd@default> <96453525-66f2-4267-b3e3-bdde6cb3b864@default> <94cbe6b3-0459-4542-8f66-4b00a0905740@default> <3f81e593-4f58-4b0e-a52c-ad05d92299dd@default> Message-ID: <5dfb9228-2308-5ccd-8dd2-2b626fc4740b@oracle.com> +1 -phil. On 04/13/2018 01:31 AM, Jayathirth D V wrote: > Hi Phil, > > Thanks for your inputs. > > I have updated the code to reflect the changes mentioned by you and changed test case to use ByteArrayInput/OutputStream. > Please find updated webrev for review: > http://cr.openjdk.java.net/~jdv/6788458/webrev.08/ > > Regards, > Jay > > -----Original Message----- > From: Phil Race > Sent: Wednesday, April 11, 2018 10:23 PM > To: Jayathirth D V; Prahalad Kumar Narayanan; 2d-dev > Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores tRNS chunk while reading non-indexed RGB images > > http://cr.openjdk.java.net/~jdv/6788458/webrev.07/src/java.desktop/share/classes/com/sun/imageio/plugins/png/PNGMetadata.java.udiff.html > > There's an extra line added at the end which you can remove. > > Why do the tests needs to create temp disk files ? > Can't we do this all with ByteArrayInput/OutputStream ? > Less worry about clean up there. > > I note that this > > 286 boolean tRNSTransparentPixelPresent = > 1287 theImage.getSampleModel().getNumBands() == inputBands + 1 && > 1288 metadata.hasTransparentColor(); > > is evaluated for each row when I expect it only needs to be evaluated once for the whole decode pass. > But the overhed is presumably low and it is next to the use so I think it should be OK as is. > > However the code that does the transparent per-pixel settings does seem needlessly wasteful. These can be moved outside at least the entire row decode : > > final int[] temp = new int[inputBands + 1]; > > final int opaque = (bitDepth < 16) ? 255 : 65535; > > Note that I added final to them .. > > Also array accesses are (relatively) slow but since you need an array to pass to setPixel and there's only two accesses I don't see how we can improve on that here by assigning the values from the ps array to local variables. > > -phil. > > > On 04/09/2018 11:19 PM, Jayathirth D V wrote: >> HI Prahalad, >> >> Thanks for your inputs. >> >> Regarding- >> Few minor corrections to PNGImageReader- . Line: 1310 >> . This missed my eye in the last review. >> . We could create int[] temp outside the for loop. I tried this with your changes & it works. >> . It's an optimization so that we don't end up creating int[] array for every pixel in the row. >> >> Before sending webrev.06, I actually made similar changes of moving temp[] creation and/or calculating "opaque" to outside of for loop. >> But this will cause creation of temp[] and/ or calculation of "opaque" for each row in all the cases where there is no RGB/Gray & tRNS combination. So I reverted those change before sending webrev.06. >> I would like to keep all the calculation specific to RGB/Gray & tRNS combination in its own code flow. >> >> Other modifications are made. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6788458/webrev.07/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Monday, April 09, 2018 2:23 PM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello Jay >> >> I looked into the latest code changes. >> The code changes are good. >> >> Few minor corrections to PNGImageReader- . Line: 1310 >> . This missed my eye in the last review. >> . We could create int[] temp outside the for loop. I tried this with your changes & it works. >> . It's an optimization so that we don't end up creating int[] array for every pixel in the row. >> >> . Line: 1320, 1329 >> . Align the opening { on the same line as the if statement. >> >> . Line: 1479 >> . Correct the indentation of the expression within if condition. >> . A suggestion that could help: >> if ((theImage.getSampleModel().getNumBands() >> == inputBandsForColorType[colorType] + 1) >> && metadata.hasTransparentColor()) { >> // code block >> checkReadParamBandSettings(param, >> ... >> } >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Friday, April 06, 2018 5:19 PM >> To: Prahalad Kumar Narayanan; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hi Prahalad, >> >> Thanks for your inputs. >> >> Regarding : >> File: PNGImageReader.java >> Line: 1329, 1342 >> . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. >> . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. >> int[] temp = new int[inputBands + 1]; >> int opaque = (bitDepth < 16) ? 255 : 65535; >> Arrays.fill(temp, opaque); >> . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. >> >> I think we should not use Arrays.fill() at this place and assign values to all the channels. It is a per pixel operation and we would be writing data twice. >> >> Instead of using Arrays.fill(), I thought of just assigning value to alpha channel: >> int[] temp = new int[inputBands + 1]; >> temp[inputBands] = (bitDepth < 16) ? 255 : 65535; if >> (metadata.tRNS_colorType == PNG_COLOR_RGB) { >> >> I think even doing this is not ideal because anyway for all the pixels we will be checking pixel data with tRNS data, and assign value in alpha channel. There is no need for us to assign some value and override it again later if a condition satisfies. >> So I am assigning opaque value to alpha channel at same place. But I have reduced the LOC by using ternary operator for determining the opaque value for alpha channel. >> >> All other changes are updated. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6788458/webrev.06/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Friday, April 06, 2018 1:42 PM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello Jay >> >> Good day to you. >> >> I looked into the latest changes. >> The code changes are nearly complete. Just a few tweaks. >> >> File: PNGImageReader.java >> Line: 1280 >> Rephrase from: >> /* >> * In case of colortype PNG_COLOR_RGB or PNG_COLOR_GRAY >> * if we have transparent pixel information from tRNS chunk >> * we need to consider that also and store proper information >> * in alpha channel. >> * >> * Also we create destination image with extra alpha channel >> * in getImageTypes() when we have tRNS chunk for colorType >> * PNG_COLOR_RGB or PNG_COLOR_GRAY. >> */ >> Rephrase to: >> /* >> * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY >> * that contain a specific transparent color (given by tRNS >> * chunk), we compare the decoded pixel color with the color >> * given by tRNS chunk to set the alpha on the destination. >> */ >> >> File: PNGImageReader.java >> Line: 1588 >> Rephrase from: >> /* >> * In case of PNG_COLOR_RGB or PNG_COLOR_GRAY, if we >> * have transparent pixel information in tRNS chunk >> * we create destination image having alpha channel. >> */ >> >> Rephrase to: >> /* >> * For PNG images of color type PNG_COLOR_RGB or PNG_COLOR_GRAY that >> * contain a specific transparent color (given by tRNS chunk), we add >> * ImageTypeSpecifier(s) that support transparency to the list of >> * supported image types. >> */ >> >> File: PNGImageReader.java >> Line(s): 1290, 1493, 1596, 1619 >> . The lines mentioned above check whether metadata has specific transparent color using- >> metadata.tRNS_present && >> (metadata.tRNS_colorType == PNG_COLOR_RGB || >> metadata.tRNS_colorType == PNG_COLOR_GRAY) >> >> . The above check is not only redundant but also metadata specific. >> . We could move the code to a common method in PNGMetadata- >> boolean hasTransparentColor() { >> return tRNS_present >> && (tRNS_colorType == PNG_COLOR_RGB >> || tRNS_colorType == PNG_COLOR_GRAY); >> } >> . I understand 1596 and 1619 check for specific color type but they can be avoided with this method as well. >> . As per the specification, tRNS values depend on the image's color type. >> . This will reduce the complex check from- >> if (theImage.getSampleModel().getNumBands() == >> inputBandsForColorType[colorType] + 1 && >> metadata.tRNS_present && >> (metadata.tRNS_colorType == PNG_COLOR_RGB || >> metadata.tRNS_colorType == PNG_COLOR_GRAY)) >> { >> to- >> if (metadata.hasTransparentColor() >> && (theImage.getSampleModel().getNumBands() == >> inputBandsForColorType[colorType] + 1)) { >> >> File: PNGImageReader.java >> Line: 1329, 1342 >> . The else block for if (check for transparent pixel) is redundant across both PNG_COLOR_RGB and PNG_COLOR_GRAY. >> . We could use Arrays.fill with opaque value and set the alpha to 0 if pixel is transparent. >> int[] temp = new int[inputBands + 1]; >> int opaque = (bitDepth < 16) ? 255 : 65535; >> Arrays.fill(temp, opaque); >> . All subsequent operations checking for transparent color value and setting alpha to 0 would be required. >> >> File: PNGImageReader.java >> All modified Lines: >> . The opening braces '{' can appear in the new line. Some engineers do follow this. >> . Since the rest of the code aligns opening braces in the same line as the ' if ' statement we could follow the same for code readability. >> >> Test File: ReadPngGrayImageWithTRNSChunk.java and >> ReadPngRGBImageWithTRNSChunk.java >> . The finally blocks should check whether the objects- ImageOutputStream and File, are not null. >> . The call to directory(while is a File).delete() is not required in my view. Verify this once. >> . Dispose the writer after the write operation is complete. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> -----Original Message----- >> From: Jayathirth D V >> Sent: Thursday, April 05, 2018 3:26 PM >> To: Prahalad Kumar Narayanan; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello Prahalad, >> >> Thank you for the inputs. >> >> I gave updated the code to not change ImageTypeSpecifier of passRow. Now while storing the pixel values into imRas we comparing the pixel RGB/Gray values to tRNS RGB/Gray values and storing appropriate value for alpha channel. >> I have added support to use tRNS_Gray value when IHDR color type is PNG_COLOR_GRAY - We are now creating 2 channel destination image whenever we see that tRNS chunk is present for PNG_COLOR_GRAY in getImageTypes(). >> isTransparentPixelPresent() code is removed and we are using available tRNS properties. >> >> I have merged previous test cases. Now we have 2 test cases each verifying the code changes for RGB & Gray image for 8 & 16 bit depth values. >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6788458/webrev.05/ >> >> Thanks, >> Jay >> >> -----Original Message----- >> From: Prahalad Kumar Narayanan >> Sent: Monday, April 02, 2018 12:03 PM >> To: Krishna Addepalli; Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello Jay >> >> Good day to you. >> >> I looked into the latest code changes. >> Please find my review observation & suggestions herewith. >> >> My understanding of problem statement: >> . As I understand, our PNGImageReader parses tRNS chunk information from metadata whenever ignoreMetadata is false or paletted image is decoded. >> . But doesn't use the transparency information contained in the chunk to return BufferedImages with alpha/ transparency. >> >> Appropriate Changes: >> >> File: PNGImageReader.java, >> Method: Iterator getImageTypes >> Line: 1633 >> . This method is internally invoked while creating BufferedImage for destination at Line 1409: >> theImage = getDestination(param, >> getImageTypes(0), >> width, >> height); >> . The move to add ImageTypeSpecifier based on BufferedImage.TYPE_4BYTE_ABGR as the first element (index: 0) of the list is good. >> >> File: PNGImageReader.java >> Method: readMetadata >> Line: 731 >> . The if check for parsing tRNS chunk even when ignoreMetadata is set to true is good. >> . The chunk's information will be needed. >> >> Other Observation & Suggestions: >> >> File: PNGImageReader.java, >> Method: decodePass >> Line: (1088 - 1112), (1277-1327) >> . In the code chunks of listed line numbers, you have modified passRow's internal type- ImageTypeSpecifier, and thus its manipulation logic as well. >> . The changes are not required in my view. Reasons are- >> . passRow corresponds to the data from input image source. >> . imgRas corresponds to the destination buffered image. >> . To return a BufferedImage with alpha/ transparency, it would suffice to update imgRas with alpha component at Line 1371. >> imRas.setPixel(dstX, dstY, ps); // if ps contains alpha, it would suffice the need. >> . However, the proposed changes modify how we interpret the source through passRow. >> . To set alpha component on imgRas, we would require comparison of color components present in passRow with that of tRNS chunk. >> . But, passRow 's internal type- ImageTypeSpecifier need not be changed. This way most of the complex code changes can be avoided. >> >> File: PNGImageReader.java, >> Method: isTransparentPixelPresent >> Line: 1545 >> . The logic of this method considers both input image source and destination bands to decide whether transparency is available. >> . In my view, The method should consider only the alpha in input image source and not the destination. >> . Here are code points where the method is invoked >> a) 1089 : To create a writable raster- passRow. passRow corresponds to the data of image source. >> b) 1279 : To update the passRow's databuffer. passRow corresponds to the data of image source. >> c) 1512 : To pass appropriate band length to checkParamBandSettings. (Hardcoded value: 4) >> d) 1632 & 1648 : To update ArrayList l based on presence of tRNS in image source. >> . Each of the locations except (c) pertain to image source and not the destination. >> . One possible solution would be to discard this method and use the existing flag tRNS_present at (c). >> >> . Besides, The proposed changes don't address images with gray scale with alpha in tRNS chunk. >> . Your first email reads- "PNG_COLOR_GRAY image with tRNS chunk(which is very rare)" >> . Just curious to know if there 's any basis for this observation ? >> . If we consider suggestions on decodePass method, I believe, we could support setting alpha values for grayscale images as well. >> >> Line: 1555 >> . Please use tRNS_colorType together with tRNS_present flag. >> >> File: PNGImageReader.java, >> Method: readMetadata >> Line: 701 >> Rephrase From: >> * Optimization: We can skip reading metadata if ignoreMetadata >> * flag is set and colorType is not PNG_COLOR_PALETTE. But we need >> * to parse only the tRNS chunk even in the case where IHDR colortype >> * is not PNG_COLOR_PALETTE, because we need tRNS chunk transparent >> * pixel information for PNG_COLOR_RGB while storing the pixel data >> * in decodePass(). >> To: >> * Optimization: We can skip reading metadata if ignoreMetadata >> * flag is set and colorType is not PNG_COLOR_PALETTE. However, >> * we parse tRNS chunk to retrieve the transparent color from the >> * metadata irrespective of the colorType. Doing so, helps >> * PNGImageReader to appropriately identify and set transparent >> * pixels in the decoded image. >> >> File: PNGMetadata.java >> Line: 271 >> . Reset the tRNS_colorType to -1 in the reset() method. >> . This will not concern if tRNS_colorType is used in conjunction with tRNS_present flag. >> . However, the new method isTransparentPixelAvailable() uses tRNS_colorType directly. >> . When the same ImageReader is used to read multiple PNG images, this could pose a problem. >> >> Thank you >> Have a good day >> >> Prahalad N. >> >> >> ----- Original Message ----- >> From: Krishna Addepalli >> Sent: Monday, April 02, 2018 11:40 AM >> To: Jayathirth D V; 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hmmm, thanks for the clarification, but this raises one more question: Now that you are initializing the colorType to an invalid value, do you need to check appropriately in all the places where the color is being used? Otherwise, it might lead to undefined behavior. >> Also, I would like you to either add a comment at the point of initialization or better yet, define another static constant of "UNDEFINED", and then set the tRNS_colorType to this value, so that the code reads correct naturally without any comments. >> >> Thanks, >> Krishna >> >> From: Jayathirth D V >> Sent: Monday, April 2, 2018 11:33 AM >> To: Krishna Addepalli ; 2d-dev >> <2d-dev at openjdk.java.net> >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hi Krishna, >> >> The constant values for different color types is : >> static final int PNG_COLOR_GRAY = 0; >> static final int PNG_COLOR_RGB = 2; >> static final int PNG_COLOR_PALETTE = 3; >> static final int PNG_COLOR_GRAY_ALPHA = 4; >> static final int PNG_COLOR_RGB_ALPHA = 6; >> >> Since tRNS_colorType is used to hold one of the above mentioned values if we don't initialize it to some unused value(here we are using -1) we will be representing PNG_COLOR_GRAY by default. >> By default the value will be -1 after the change and after we parse tRNS chunk it will contain appropriate value. The initialization of tRNS_colorType change can be considered as newly added check. >> >> Thanks, >> Jay >> >> From: Krishna Addepalli >> Sent: Monday, April 02, 2018 9:56 AM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hi Jay, >> >> The changes look fine. However, I have one more question: Why did you have to explicitly specify the initial value to "tRNS_colorType" in PNGMetadata.java? How is it affecting your implementation? >> >> Thanks, >> Krishna >> >> From: Jayathirth D V >> Sent: Wednesday, March 28, 2018 1:43 PM >> To: Krishna Addepalli ; 2d-dev >> <2d-dev at openjdk.java.net> >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hi Krishna, >> >> Thanks for providing the inputs. >> >> 1. I suggest to rename considerTransparentPixel as isAlphaPresent. >> As discussed I have added new name as isTransparentPixelPresent() >> >> 2. You can refactor the function body as below: >> Return ((destinationBands == null || >> destinationBands.length == 4) && >> metadata.tRNS_colorType == PNG_COLOR_RGB); >> >> Changes are made. >> >> 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. >> >> Previous to this change all the values like inputsBands, bytesPerRow, eltsPerRow were same between the decoded output and destination image. >> Now because we are changing only the destination image due to the presence of transparent pixel, we need both these set of values. inputsBands, bytesPerRow, eltsPerRow will be used for decoded output and destBands, destEltsPerRow for destination image. Its better if don't mingle code flow or variables between these two code paths. >> >> 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: >> for (int i = 0; i < passWidth; i++) { >> byteData[destidx] = curr[srcidx]; >> byteData[destidx + 1] = curr[srcidx + 1]; >> byteData[destidx + 2] = curr[srcidx + 2]; >> if (curr[srcidx] == (byte)metadata.tRNS_red && >> curr[srcidx + 1] == (byte)metadata.tRNS_green && >> curr[srcidx + 2] == (byte)metadata.tRNS_blue) >> { >> byteData[destidx + 3] = (byte)0; >> } else { >> byteData[destidx + 3] = (byte)255; >> } >> srcidx += 3; >> destidx += 4; >> } >> Same thing can be done for the loop that executes for 16bit pixel data. >> >> Changes are made. >> >> >> Please find updated webrev for review : >> http://cr.openjdk.java.net/~jdv/6788458/webrev.03/ >> >> Thanks, >> Jay >> >> From: Krishna Addepalli >> Sent: Wednesday, March 28, 2018 11:52 AM >> To: Jayathirth D V; 2d-dev >> Subject: RE: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hi Jay, >> >> I have some points as below: >> 1. I suggest to rename considerTransparentPixel as isAlphaPresent. >> 2. You can refactor the function body as below: >> Return ((destinationBands == null || >> destinationBands.length == 4) && >> metadata.tRNS_colorType == PNG_COLOR_RGB); 3. From line 1088 through 1113, I see some repeated calculations like bytesPerRow etc. Why can't we reuse the previously defined variables? Apart from destBands, all the other calculations look similar and repeated. >> 4. When you are copying the pixels to a writable raster, at line 1273, you could reduce the repetition of the lines, by just having one statement inside if as below: >> for (int i = 0; i < passWidth; i++) { >> byteData[destidx] = curr[srcidx]; >> byteData[destidx + 1] = curr[srcidx + 1]; >> byteData[destidx + 2] = curr[srcidx + 2]; >> if (curr[srcidx] == (byte)metadata.tRNS_red && >> curr[srcidx + 1] == (byte)metadata.tRNS_green && >> curr[srcidx + 2] == (byte)metadata.tRNS_blue) >> { >> byteData[destidx + 3] = (byte)0; >> } else { >> byteData[destidx + 3] = (byte)255; >> } >> srcidx += 3; >> destidx += 4; >> } >> Same thing can be done for the loop that executes for 16bit pixel data. >> >> >> I haven't yet checked the test cases. >> >> Thanks, >> Krishna >> >> >> From: Jayathirth D V >> Sent: Wednesday, March 28, 2018 9:52 AM >> To: 2d-dev <2d-dev at openjdk.java.net> >> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello All, >> >> I have enhanced both the test case to verify pixels which not only match tRNS transparent pixel data but also for them which doesn't match tRNS transparent pixel data. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6788458/webrev.02/ >> >> Thanks, >> Jay >> >> From: Jayathirth D V >> Sent: Wednesday, March 28, 2018 8:28 AM >> To: 2d-dev >> Subject: Re: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader >> ignores tRNS chunk while reading non-indexed RGB images >> >> Hello All, >> >> I just realized that the test case Read16BitPNGWithTRNSChunk.java is creating (50, 50) image(which was done while debugging the issue), which is not needed as we need single pixel to verify the fix as it is done in Read8BitPNGWithTRNSChunk.java. I have updated Read16BitPNGWithTRNSChunk.java to reflect this small change. >> >> Please find updated webrev for review: >> http://cr.openjdk.java.net/~jdv/6788458/webrev.01/ >> >> Thanks, >> Jay >> >> From: Jayathirth D V >> Sent: Tuesday, March 27, 2018 6:51 PM >> To: 2d-dev >> Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6788458: PNGImageReader ignores >> tRNS chunk while reading non-indexed RGB images >> >> Hello All, >> >> Please review the following solution in JDK11 : >> >> Bug : https://bugs.openjdk.java.net/browse/JDK-6788458 >> Webrev : http://cr.openjdk.java.net/~jdv/6788458/webrev.00/ >> >> Issue: When we try to read non-indexed RGB PNG image having transparent pixel information in tRNS chunk, ImageIO.PNGImageReader ignores the transparent pixel information. If we use Toolkit.getDefaultToolkit().createImage() it doesn't ignore the transparent pixel information. >> >> Root cause: In ImageIO.PNGImageReader() we store tRNS chunk values in readMetadata() -> parse_tRNS_chunk (), but we never use the tRNS R, G, B value to compare with decoded image information. Also in ImageIO.PNGImageReader() for IHDR colortype RGB we use only 3 channel destination BufferedImage. So even if we use the tRNS chunk value we need destination BufferedImage of 4 channels to represent transparency. >> >> Solution: While assigning destination image in PNGImageReader.getImageTypes() if we know that PNG image is of type RGB and has tRNS chunk then we need to assign a destination image having 4 channels. After that in decodePass() we need to create 4 channel destination raster and while we store decoded image information into the destination BufferedImage we need to compare decoded R, G, B values with tRNS R, G, B values and store appropriate alpha channel value. >> >> Also we use 4 channel destination image in case of RGB image only when tRNS chunk is present and ImageReadParam.destinationBands is null or ImageReadParam.destinationBands is equal to 4. >> >> One more change is that we have optimization in PNGImageReader.readMetadata() where if ignoreMetadata is true and IHDR colortype is not of type PNG_COLOR_PALETTE, we ignore all the chunk data and just try to find first IDAT chunk. But if we need tRNS chunk values in case of IHDR colortype PNG_COLOR_RGB we need to parse tNRS chunk also. So in readMetadata() also appropriate changes are made. >> >> Note : Initially the enhancement request was present only for 8 bit RGB PNG images but after making more modifications realized that we can add support for 16 bit RGB image also by making similar incremental changes. The tRNS chunk value is still ignored for Gray PNG image. If we need to support PNG_COLOR_GRAY image with tRNS chunk(which is very rare) we can take that up in a separate bug as it needs different set of changes. >> >> Thanks, >> Jay From philip.race at oracle.com Tue Apr 17 15:31:38 2018 From: philip.race at oracle.com (Phil Race) Date: Tue, 17 Apr 2018 08:31:38 -0700 Subject: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter incorrectly sets bKGD chunk In-Reply-To: <0d5098be-be61-4c3c-8d59-850c002f5b61@default> References: <7d979cd1-97d2-40f8-ad89-03f33da27058@default> <8f34e23e-b5e8-4436-8f62-2ff859cef583@default> <8b49fe59-0122-47d9-ac63-7b3b202eb269@default> <0d5098be-be61-4c3c-8d59-850c002f5b61@default> Message-ID: <61bd504e-f8a0-41f8-8a7c-5dbb150eedac@oracle.com> +1 from me .. -phil. On 04/17/2018 02:27 AM, Prahalad Kumar Narayanan wrote: > > Hello Jay > > Changes are good. > > Thanks > > Have a good day > > Prahalad N. > > *From:*Jayathirth D V > *Sent:* Tuesday, April 17, 2018 2:23 PM > *To:* Prahalad Kumar Narayanan; Philip Race; 2d-dev > *Subject:* RE: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter > incorrectly sets bKGD chunk > > Hi Prahalad, > > Thanks for the review. > > I have updated the test case to dispose the image reader. > > Please find updated webrev: > > http://cr.openjdk.java.net/~jdv/6574555/webrev.02/ > > > Regards, > > Jay > > *From:*Prahalad Kumar Narayanan > *Sent:* Tuesday, April 17, 2018 11:50 AM > *To:* Jayathirth D V; Philip Race; 2d-dev > *Subject:* RE: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter > incorrectly sets bKGD chunk > > Hello Jay > > The changes are fine. > > Just a minor observation: The image reader should be disposed in the > test case. > > Thank you > > Have a good day > > Prahalad N. > > *From:*Jayathirth D V > *Sent:* Friday, April 13, 2018 2:24 PM > *To:* Philip Race; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter > incorrectly sets bKGD chunk > > Hi Phil, > > Thanks for your inputs. > > I have modified the test case to use ByteArrayOutput/InputStream. > > Please find updated webrev for review: > > http://cr.openjdk.java.net/~jdv/6574555/webrev.01/ > > > Regards, > > Jay > > *From:*Phil Race > *Sent:* Wednesday, April 11, 2018 10:40 PM > *To:* Jayathirth D V; 2d-dev > *Subject:* Re: [OpenJDK 2D-Dev] [11] RFR JDK-6574555: PNGImageWriter > incorrectly sets bKGD chunk > > The fix seems fine but like the other review I wonder if > the test can use a bytearrayoutputstream instead of writing to a file. > > -phil. > > On 04/11/2018 03:51 AM, Jayathirth D V wrote: > > Hello All, > > Please review the following fix in JDK11 : > > Bug : https://bugs.openjdk.java.net/browse/JDK-6574555 > > Webrev : http://cr.openjdk.java.net/~jdv/6574555/webrev.00/ > > > _Issue:_ PNGImageWriter. write_bKGD() function sets incorrect R, > G, B value when IHDR colortype and bKGD colortype is PNG_COLOR_RGB(A). > > _Solution:_ Assign values to all channels of RGB as they are > present in Metadata instead of using only bKGD red value. > > _Note_ : Our default metadata doesn?t set any bKGD chunk but if > user specifies bKGD chunk and uses mergeTree() then we check bKGD > R, G, B values and if r == g == b then we store bKGD chunk as of > type PNG_COLOR_GRAY. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Wed Apr 18 10:04:25 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 18 Apr 2018 03:04:25 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete In-Reply-To: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> References: <6f63be23-a3dc-482e-b234-8c423a2a1755@default> Message-ID: Hello All, Since changes related to JDK-6574555 is pushed. Please find new webrev which captures test case changes over JDK-6574555. http://cr.openjdk.java.net/~jdv/5109146/webrev.01/ Thanks, Jay From: Jayathirth D V Sent: Tuesday, April 17, 2018 3:34 PM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] RFR JDK-5109146: PNGMetadata Background color initialization from standard metadata is incomplete Hello All, Please review the following fix in JDK11 : Bug : https://bugs.openjdk.java.net/browse/JDK-5109146 Webrev : http://cr.openjdk.java.net/~jdv/5109146/webrev.00/ Issue: PNGMetadata.mergeStandardTree() function doesn't set proper bKGD colortype. Solution: When bKGD R, G, B values are unique we need to store appropriate bKGD colortype in metadata. Note : Test case which is present as part of review in JDK-6574555 is only updated to handle regression scenario for this bug also. Regression scenario between this bug and JDK-6574555 differ only in what type(native/standard) metadata we use to merge bKGD RGB values. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikael.vidstedt at oracle.com Thu Apr 19 22:41:35 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 19 Apr 2018 15:41:35 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8202052: Disable warnings when building libawt with VS2017 Message-ID: Please review the following change which disables some warnings in libawt which show up when building with VS2017: bug: https://bugs.openjdk.java.net/browse/JDK-8202052 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ Please note that I also filed an issue which covers addressing these warnings in the Right(tm) way (and then removing the disabling of the warnings): https://bugs.openjdk.java.net/browse/JDK-8202051 I have tested this with VS2017, and will also verify that it works with the existing toolchain version (used at Oracle). Cheers, Mikael -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Apr 19 22:51:00 2018 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Apr 2018 15:51:00 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8202052: Disable warnings when building libawt with VS2017 In-Reply-To: References: Message-ID: <5AD91D54.40609@oracle.com> +1 -phil. On 4/19/18, 3:41 PM, Mikael Vidstedt wrote: > > Please review the following change which disables some warnings in > libawt which show up when building with VS2017: > > bug: https://bugs.openjdk.java.net/browse/JDK-8202052 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ > > > > Please note that I also filed an issue which covers addressing these > warnings in the Right(tm) way (and then removing the disabling of the > warnings): > > https://bugs.openjdk.java.net/browse/JDK-8202051 > > > I have tested this with VS2017, and will also verify that it works > with the existing toolchain version (used at Oracle). > > Cheers, > Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik.joelsson at oracle.com Thu Apr 19 22:54:43 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 19 Apr 2018 15:54:43 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8202052: Disable warnings when building libawt with VS2017 In-Reply-To: References: Message-ID: Looks good. /Erik On 2018-04-19 15:41, Mikael Vidstedt wrote: > Please review the following change which disables some warnings in libawt which show up when building with VS2017: > > bug: https://bugs.openjdk.java.net/browse/JDK-8202052 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8202062/webrev.00/open/webrev/ > > > Please note that I also filed an issue which covers addressing these warnings in the Right(tm) way (and then removing the disabling of the warnings): > > https://bugs.openjdk.java.net/browse/JDK-8202051 > > > I have tested this with VS2017, and will also verify that it works with the existing toolchain version (used at Oracle). > > Cheers, > Mikael > From alexey.ivanov at oracle.com Mon Apr 23 10:44:03 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 23 Apr 2018 11:44:03 +0100 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM Message-ID: <67d364ee-8d47-c8a2-d9e1-3f734e8f399e@oracle.com> Hi, Could you please review the following backport to 8u-dev? jbs: https://bugs.openjdk.java.net/browse/JDK-8201433 review: http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009129.html jdk11 changeset: http://hg.openjdk.java.net/jdk/client/rev/4ed714d1f90b The patch does not apply cleanly to 8u: webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk8/webrev.0/ Thank you! Regards, Alexey From alexey.ivanov at oracle.com Mon Apr 23 10:49:46 2018 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Mon, 23 Apr 2018 11:49:46 +0100 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR for JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData Message-ID: Hi, Could you please review the following backport to 8u-dev? jbs: https://bugs.openjdk.java.net/browse/JDK-8201240 review: http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009122.html jdk11 changeset: http://hg.openjdk.java.net/jdk/client/rev/69f7e3ed043c The patch does not apply cleanly to 8u and also requires changes to map files: webrev: http://cr.openjdk.java.net/~aivanov/8201240/jdk8/webrev.0/ Thank you! Regards, Alexey From Sergey.Bylokhov at oracle.com Mon Apr 23 23:44:42 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 16:44:42 -0700 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR for JDK-8201433: Fix potential crash in BufImg_SetupICM In-Reply-To: <67d364ee-8d47-c8a2-d9e1-3f734e8f399e@oracle.com> References: <67d364ee-8d47-c8a2-d9e1-3f734e8f399e@oracle.com> Message-ID: <8863f361-4335-5f46-e5ab-6295822fadcf@oracle.com> Looks fine. On 23/04/2018 03:44, Alexey Ivanov wrote: > Hi, > > Could you please review the following backport to 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8201433 > review: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009129.html > jdk11 changeset: http://hg.openjdk.java.net/jdk/client/rev/4ed714d1f90b > > > The patch does not apply cleanly to 8u: > webrev: http://cr.openjdk.java.net/~aivanov/8201433/jdk8/webrev.0/ > > Thank you! > > Regards, > Alexey -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Apr 23 23:46:18 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Apr 2018 16:46:18 -0700 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR for JDK-8201240: Improve releasing native resources of BufImgSurfaceData.ICMColorData In-Reply-To: References: Message-ID: Looks fine. On 23/04/2018 03:49, Alexey Ivanov wrote: > Hi, > > Could you please review the following backport to 8u-dev? > > jbs: https://bugs.openjdk.java.net/browse/JDK-8201240 > review: > http://mail.openjdk.java.net/pipermail/2d-dev/2018-April/009122.html > jdk11 changeset: http://hg.openjdk.java.net/jdk/client/rev/69f7e3ed043c > > > The patch does not apply cleanly to 8u and also requires changes to map > files: > webrev: http://cr.openjdk.java.net/~aivanov/8201240/jdk8/webrev.0/ > > Thank you! > > Regards, > Alexey -- Best regards, Sergey. From srloomis at us.ibm.com Wed Apr 25 15:26:25 2018 From: srloomis at us.ibm.com (Steven R Loomis) Date: Wed, 25 Apr 2018 15:26:25 +0000 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors Message-ID: An HTML attachment was scrubbed... URL: From srl295 at gmail.com Wed Apr 25 15:39:45 2018 From: srl295 at gmail.com (Steven R. Loomis) Date: Wed, 25 Apr 2018 08:39:45 -0700 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors (Resend) Message-ID: (Retrying as actual text) Support Unicode Variation Selectors. Code by my colleague Toshio Nakamura, I added a simple test, and include a test that was part of JDK 8187100. (Both tests are run manually.) Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > Hello > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > and Swing components. > (This proposal was posted to i18n-dev first, and I got a suggestion to > discuss > in 2d-dev.) > > This proposal changed the following files: > src/java.desktop/share/classes/sun/font/CMap.java > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > src/java.desktop/share/classes/sun/font/Font2D.java > src/java.desktop/share/classes/sun/font/FontRunIterator.java > src/java.desktop/share/classes/sun/font/FontUtilities.java > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > src/java.desktop/share/native/common/font/sunfontids.h > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > src/java.desktop/share/native/libfontmanager/sunFont.c > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > 542 lines will be changed. > > There are three parts. > 1) Adding CMap format 14 support > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > 3) Swing text component's DEL and BS key operations change > > > How would I go about obtaining a sponsor? > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > Chapter 23.4 Variation Selectors > > Best regards, > > Toshio Nakamura > IBM Japan -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam.farley at uk.ibm.com Wed Apr 25 15:43:03 2018 From: adam.farley at uk.ibm.com (Adam Farley8) Date: Wed, 25 Apr 2018 16:43:03 +0100 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c Message-ID: Hi All, Does anyone have an objection to pushing this tiny change in? It doesn't break anything, it fixes a build break on two supported platforms, and it seems like we never refresh the code from upstream. - Adam > I also advocate the source code fix, as Make isn't meant to use the sort of logic required > to properly analyse the toolchain version string. > > e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and Make doesn't > seem to do substring stuff unless you mess around with shells. > > Plus, as people have said, it's better to solve problem x (or work around a specific > instance of x) than to ignore the exception, even if the ignoring code is toolchain- > specific. > > - Adam Farley > > > On 2018-03-27 18:44, Phil Race wrote: > > > >> As I said I prefer the make file change, since this is a change to an upstream library. > > > > Newtons fourth law: For every reviewer, there's an equal and opposite reviewer. :) > > > > Here I am, advocating a source code fix. As Thomas says, the compiler complaint seems reasonable, and disabling it might cause us to miss other future errors. > > > > Why can't we push the source code fix, and also submit it upstream? > > > > /Magnus > > > > > > I've looked at jpeg-9c and it still looks identical to what we have in 6b, so this code > > seems to have stood the test of time. I'm also unclear why the compiler would > > complain about that and not the one a few lines later > > > > > > 819 while (bits[i] == 0) /* find largest codelength still in use */ > > 820 i--; > > > > A push to jchuff.c will get blown away if/when we upgrade. > > A tool-chain specific fix in the makefile with an appropriate comment is more targeted. > > Phil, > > Returning to this. > > While I understand your reluctance to patch upstream code, let me point out that we have not updated libjpeg a single time since the JDK was open sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page on libjpeg, and this is the latest "uncontroversial" version of the source. Versions 7 and up have proprietary extensions, which in turn has resulted in multiple forks of libjpeg. As it stands, it seems unlikely that we will ever replace libjpeg 6b with a simple upgrade from upstream. > > I therefore maintain my position that a source code fix would be the best way forward here. > > /Magnus > > > > > > > -phil. > > > > > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > > Hi all, > > > > > > just a friendly reminder. I would like to push this tiny fix because tripping over this on our linux s390x builds is annoying (yes, we can maintain patch queues, but this is a constant error source). > > > > > > I will wait for 24 more hours until a reaction. If no serious objections are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph langer are both Reviewers). > > > > > > Thanks! Thomas > > > > > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe wrote: > > > > Hi all, > > > > > > may I please have another review for this really trivial change. It fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix this. > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > > > > This was contributed by Adam Farley at IBM. > > > > > > I already reviewed this. I also test-built on zlinux and it works. > > > > > > Thanks, Thomas > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From TOSHIONA at jp.ibm.com Wed Apr 25 16:03:35 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 26 Apr 2018 01:03:35 +0900 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors(Resend) In-Reply-To: References: Message-ID: Hi Steven, Thank you for becoming the sponsor of my proposal and creating an official Webrev and tests. Of course, they are fine for me. Toshio Nakamura From: "Steven R. Loomis" To: 2d-dev <2d-dev at openjdk.java.net> Date: 2018/04/26 00:41 Subject: [OpenJDK 2D-Dev] RFR: JDK-8187100: support Variation Selectors (Resend) Sent by: "2d-dev" <2d-dev-bounces at openjdk.java.net> (Retrying as actual text) Support Unicode Variation Selectors. Code by my colleague Toshio Nakamura, ?I added a simple test, and include a test that was part of JDK 8187100. (Both tests are run manually.) Bug: https://bugs.openjdk.java.net/browse/JDK-8187100 Webrev: http://cr.openjdk.java.net/~srl/8187100/webrev.00/ On 04/08/2018 11:46 PM, Toshio 5 Nakamura wrote: > > Hello > > IBM would like to propose Unicode Variation Selector[1] capability to AWT > and Swing components. > (This proposal was posted to i18n-dev first, and I got a suggestion to > discuss > ?in 2d-dev.) > > This proposal changed the following files: > src/java.desktop/share/classes/sun/font/CMap.java > src/java.desktop/share/classes/sun/font/CharToGlyphMapper.java > src/java.desktop/share/classes/sun/font/CompositeGlyphMapper.java > src/java.desktop/share/classes/sun/font/Font2D.java > src/java.desktop/share/classes/sun/font/FontRunIterator.java > src/java.desktop/share/classes/sun/font/FontUtilities.java > src/java.desktop/share/classes/sun/font/TrueTypeGlyphMapper.java > src/java.desktop/share/native/common/font/sunfontids.h > src/java.desktop/share/native/libfontmanager/hb-jdk-font.cc > src/java.desktop/share/native/libfontmanager/sunFont.c > src/java.desktop/share/classes/javax/swing/text/DefaultEditorKit.java > 542 lines will be changed. > > There are three parts. > 1) Adding CMap format 14 support > 2) Adding CharsToGlyphs functions support Variation Selector Sequences > 3) Swing text component's DEL and BS key operations change > > > How would I go about obtaining a sponsor? > > [1] _http://www.unicode.org/versions/Unicode10.0.0/ch23.pdf_ > ? ? ?Chapter 23.4 Variation Selectors > > Best regards, > > Toshio Nakamura > IBM Japan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From Sergey.Bylokhov at oracle.com Thu Apr 26 05:32:21 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 25 Apr 2018 22:32:21 -0700 Subject: [OpenJDK 2D-Dev] [11] Review Request: 8202301 Add tests related to JDK-8196572 to the ProblemList Message-ID: <7d422b63-280c-c492-336c-c66e0eb046c3@oracle.com> Hello. Please review small update for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8202301 A few tests added to the problemlist. These tests will be fixed in: https://bugs.openjdk.java.net/browse/JDK-8196572 Fix is inline below: diff -r 48637783b4f6 test/jdk/ProblemList.txt sun/awt/shell/ShellFolderMemoryLeak.java 8197794 windows-all +sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java 8196572 generic-all +sun/java2d/cmm/ColorConvertOp/MTColConvTest.java 8196572 generic-all sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java 8022403 generic-all -- Best regards, Sergey. From jayathirth.d.v at oracle.com Thu Apr 26 05:32:05 2018 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Wed, 25 Apr 2018 22:32:05 -0700 (PDT) Subject: [OpenJDK 2D-Dev] [11] Review Request: 8202301 Add tests related to JDK-8196572 to the ProblemList In-Reply-To: <7d422b63-280c-c492-336c-c66e0eb046c3@oracle.com> References: <7d422b63-280c-c492-336c-c66e0eb046c3@oracle.com> Message-ID: +1 -----Original Message----- From: Sergey Bylokhov Sent: Thursday, April 26, 2018 11:02 AM To: 2d-dev Subject: [OpenJDK 2D-Dev] [11] Review Request: 8202301 Add tests related to JDK-8196572 to the ProblemList Hello. Please review small update for jdk11. Bug: https://bugs.openjdk.java.net/browse/JDK-8202301 A few tests added to the problemlist. These tests will be fixed in: https://bugs.openjdk.java.net/browse/JDK-8196572 Fix is inline below: diff -r 48637783b4f6 test/jdk/ProblemList.txt sun/awt/shell/ShellFolderMemoryLeak.java 8197794 windows-all +sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java 8196572 generic-all +sun/java2d/cmm/ColorConvertOp/MTColConvTest.java 8196572 generic-all sun/java2d/DirectX/OnScreenRenderingResizeTest/OnScreenRenderingResizeTest.java 8022403 generic-all -- Best regards, Sergey. From magnus.ihse.bursie at oracle.com Thu Apr 26 08:39:13 2018 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 26 Apr 2018 10:39:13 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: References: Message-ID: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> I don't object, but it's not build code so I don't have the final say. /Magnus On 2018-04-25 17:43, Adam Farley8 wrote: > Hi All, > > Does anyone have an objection to pushing this tiny change in? > > It doesn't break anything, it fixes a build break on two supported > platforms, and it seems > like we never refresh the code from upstream. > > - Adam > > > I also advocate the source code fix, as Make isn't meant to use the sort of > logic required > > to properly analyse the toolchain version string. > > > > e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, and > Make doesn't > > seem to do substring stuff unless you mess around with shells. > > > > Plus, as people have said, it's better to solve problem x (or work around a > specific > > instance of x) than to ignore the exception, even if the ignoring code is > toolchain- > > specific. > > > > - Adam Farley > > > > > On 2018-03-27 18:44, Phil Race wrote: > > > > > >> As I said I prefer the make file change, since this is a change to an > upstream library. > > > > > > Newtons fourth law: For every reviewer, there's an equal and opposite > reviewer. :) > > > > > > Here I am, advocating a source code fix. As Thomas says, the compiler > complaint seems reasonable, and disabling it might cause us to miss > other future errors. > > > > > > Why can't we push the source code fix, and also submit it upstream? > > > > > > /Magnus > > > > > > > > > I've looked at jpeg-9c and it still looks identical to what we have > in 6b, so this code > > > seems to have stood the test of time. I'm also unclear why the > compiler would > > > complain about that and not the one a few lines later > > > > > > > > > ?819 ? while (bits[i] == 0) ? ? ? ? ?/* find largest codelength still > in use */ > > > ?820 ? ? i--; > > > > > > A push to jchuff.c will get blown away if/when we upgrade. > > > A tool-chain specific fix in the makefile with an appropriate comment > is more targeted. > > > > Phil, > > > > Returning to this. > > > > While I understand your reluctance to patch upstream code, let me > point out that we have not updated libjpeg a single time since the JDK > was open sourced. We're using 6b from 27-Mar-1998. I had a look at the > Wikipedia page on libjpeg, and this is the latest "uncontroversial" > version of the source.Versions 7 and up have proprietary extensions, > which in turn has resulted in multiple forks of libjpeg. As it stands, > it seems unlikely that we will ever replace libjpeg 6b with a simple > upgrade from upstream. > > > > I therefore maintain my position that a source code fix would be the > best way forward here. > > > > /Magnus > > > > > > > > > > > -phil. > > > > > > > > > On 03/27/2018 05:44 AM, Thomas St?fe wrote: > > > > > > Hi all, > > > > > > > > > just a friendly reminder. I would like to push this tiny fix because > tripping over this on our linux s390x builds is annoying (yes, we can > maintain patch queues, but this is a constant error source). > > > > > > > > > I will wait for 24 more hours until a reaction. If no serious > objections are forcoming, I want to push it (tier1 tests ran thru, and > me and Christoph langer are both Reviewers). > > > > > > > > > Thanks! Thomas > > > > > > > > > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe > wrote: > > > > > > Hi all, > > > > > > > > > may I please have another review for this really trivial change. It fixes > a gcc warning on s390 and ppc. Also, it is probably a good idea to fix > this. > > > > > > > > > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 > > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ > > > > > > > > > > > This was contributed by Adam Farley at IBM. > > > > > > > > > I already reviewed this. I also test-built on zlinux and it works. > > > > > > > > > Thanks, Thomas > > > > > > > Unless stated otherwise above: > > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > > > > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with > number 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.stuefe at gmail.com Thu Apr 26 09:46:40 2018 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 26 Apr 2018 11:46:40 +0200 Subject: [OpenJDK 2D-Dev] RFR(xxxs): 8200052: libjavajpeg: Fix compile warning in jchuff.c In-Reply-To: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> References: <5b56ba86-03d5-c5b0-6733-36f40ba441bc@oracle.com> Message-ID: Same here. I would like to have this fix in, but do not want to go over Phils head. I think Phil was the main objector, maybe he could reconsider?` Thanks, Thomas On Thu, Apr 26, 2018 at 10:39 AM, Magnus Ihse Bursie wrote: > I don't object, but it's not build code so I don't have the final say. > > /Magnus > > > On 2018-04-25 17:43, Adam Farley8 wrote: > > Hi All, > > Does anyone have an objection to pushing this tiny change in? > > It doesn't break anything, it fixes a build break on two supported > platforms, and it seems > like we never refresh the code from upstream. > > - Adam > >> I also advocate the source code fix, as Make isn't meant to use the sort >> of logic required >> to properly analyse the toolchain version string. >> >> e.g. An "eq" match on 4.8.5 doesn't protect the user who is using 4.8.6, >> and Make doesn't >> seem to do substring stuff unless you mess around with shells. >> >> Plus, as people have said, it's better to solve problem x (or work around >> a specific >> instance of x) than to ignore the exception, even if the ignoring code is >> toolchain- >> specific. >> >> - Adam Farley >> >> > On 2018-03-27 18:44, Phil Race wrote: >> > >> >> As I said I prefer the make file change, since this is a change to an >> >> upstream library. >> > >> > Newtons fourth law: For every reviewer, there's an equal and opposite >> > reviewer. :) >> > >> > Here I am, advocating a source code fix. As Thomas says, the compiler >> > complaint seems reasonable, and disabling it might cause us to miss other >> > future errors. >> > >> > Why can't we push the source code fix, and also submit it upstream? >> > >> > /Magnus >> > >> > >> > I've looked at jpeg-9c and it still looks identical to what we have in >> > 6b, so this code >> > seems to have stood the test of time. I'm also unclear why the compiler >> > would >> > complain about that and not the one a few lines later >> > >> > >> > 819 while (bits[i] == 0) /* find largest codelength still in >> > use */ >> > 820 i--; >> > >> > A push to jchuff.c will get blown away if/when we upgrade. >> > A tool-chain specific fix in the makefile with an appropriate comment is >> > more targeted. >> >> Phil, >> >> Returning to this. >> >> While I understand your reluctance to patch upstream code, let me point >> out that we have not updated libjpeg a single time since the JDK was open >> sourced. We're using 6b from 27-Mar-1998. I had a look at the Wikipedia page >> on libjpeg, and this is the latest "uncontroversial" version of the source. >> Versions 7 and up have proprietary extensions, which in turn has resulted in >> multiple forks of libjpeg. As it stands, it seems unlikely that we will ever >> replace libjpeg 6b with a simple upgrade from upstream. >> >> I therefore maintain my position that a source code fix would be the best >> way forward here. >> >> /Magnus >> >> > >> > >> > -phil. >> > >> > >> > On 03/27/2018 05:44 AM, Thomas St?fe wrote: >> > >> > Hi all, >> > >> > >> > just a friendly reminder. I would like to push this tiny fix because >> > tripping over this on our linux s390x builds is annoying (yes, we can >> > maintain patch queues, but this is a constant error source). >> > >> > >> > I will wait for 24 more hours until a reaction. If no serious objections >> > are forcoming, I want to push it (tier1 tests ran thru, and me and Christoph >> > langer are both Reviewers). >> > >> > >> > Thanks! Thomas >> > >> > >> > On Wed, Mar 21, 2018 at 6:20 PM, Thomas St?fe >> > wrote: >> > >> > Hi all, >> > >> > >> > may I please have another review for this really trivial change. It >> > fixes a gcc warning on s390 and ppc. Also, it is probably a good idea to fix >> > this. >> > >> > >> > bug: https://bugs.openjdk.java.net/browse/JDK-8200052 >> > webrev: >> > http://cr.openjdk.java.net/~stuefe/webrevs/8200052-fix-warning-in-jchuff.c/webrev.00/webrev/ >> > >> > >> > This was contributed by Adam Farley at IBM. >> > >> > >> > I already reviewed this. I also test-built on zlinux and it works. >> > >> > >> > Thanks, Thomas >> > >> >> Unless stated otherwise above: >> IBM United Kingdom Limited - Registered in England and Wales with number >> 741598. >> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU >> >> > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > > From Sergey.Bylokhov at oracle.com Mon Apr 30 15:33:03 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 30 Apr 2018 08:33:03 -0700 Subject: [OpenJDK 2D-Dev] RFR 8197388: Added not existing bug id in jdk/ProblemList.txt In-Reply-To: <866F7B21-C3B0-4F13-8C26-D085B8636A09@oracle.com> References: <1AD251EC-4B2B-4F14-8F97-004CFD2B0A87@oracle.com> <866F7B21-C3B0-4F13-8C26-D085B8636A09@oracle.com> Message-ID: <7f9467b0-0814-0a9f-81a5-cfe5182560e2@oracle.com> @2d-dev is added. The fix looks fine. On 27/04/2018 13:56, Andrey Nazarov wrote: > Hi, > > Could you CC any client alias? > > ?Thanks, > Andrei > >> On 26 Apr 2018, at 11:51, Andrey Nazarov wrote: >> >> Hi, >> >> Please review patch that fixes typo in bug id. >> >> diff -r 3661f31c6df4 test/jdk/ProblemList.txt >> --- a/test/jdk/ProblemList.txt Thu Apr 26 11:19:05 2018 -0500 >> +++ b/test/jdk/ProblemList.txt Thu Apr 26 11:47:18 2018 -0700 >> @@ -243,7 +243,7 @@ >> sun/java2d/SunGraphics2D/EmptyClipRenderingTest.java 8144029 macosx-all >> sun/java2d/SunGraphics2D/DrawImageBilinear.java 8191506 generic-all >> sun/java2d/SunGraphics2D/PolyVertTest.java 6986565 generic-all >> -sun/java2d/SunGraphics2D/SimplePrimQuality.java 7992007 generic-all >> +sun/java2d/SunGraphics2D/SimplePrimQuality.java 6992007 generic-all >> sun/java2d/SunGraphics2D/SourceClippingBlitTest/SourceClippingBlitTest.java 8196191 windows-all,macosx-all >> sun/java2d/pipe/InterpolationQualityTest.java 8171303 windows-all,linux-all,macosx-all >> java/awt/FullScreen/DisplayChangeVITest/DisplayChangeVITest.java 8169469 windows-all >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8197388 >> >> >> ?Thanks, >> Andrei > -- Best regards, Sergey.