From prasanta.sadhukhan at oracle.com Mon Nov 2 05:33:14 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 2 Nov 2015 11:03:14 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8139216: Non-ASCII characters in CUPS printer names are not properly displayed In-Reply-To: <5633B264.2000509@oracle.com> References: <561F8411.9000806@oracle.com> <562DCEA0.3040605@oracle.com> <56326D8C.5080406@oracle.com> <5632FDED.6040106@oracle.com> <5633B264.2000509@oracle.com> Message-ID: <5636F59A.4090602@oracle.com> Thanks Phil. I need +1 for this. @Sergey, could you please review and approve it? Regards Prasanta On 10/30/2015 11:39 PM, Phil Race wrote: > Ok .. approved. > > -phil. > > On 10/29/2015 10:19 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 10/30/2015 12:33 AM, Phil Race wrote: >>> On 10/25/2015 11:56 PM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> I have modified the fix to assign printer name in case >>>> UnsupportedEncodingException is thrown which is unlikely as we are >>>> using UTF-8 as character encoding and not any user-supplied encoding. >>>> http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.01/ >>> >>> It should be impossible as it would contradict the SE spec to not >>> support UTF-8 >>> https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html >>> >>> Anyway, off-list you said that even with this change you could not then >>> open a connection because URLConnection was throwing an >>> IOException. Is that somehow resolved ?? >>> >> I was trying a different approach that time which was causing that >> problem. This fix does not have that problem and works. >> >> Regards >> Prasanta >>> -phil. >>> >>>> >>>> Regards >>>> Prasanta >>>> On 10/15/2015 4:16 PM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for jdk9 where it was found that non-ASCII >>>>> characters in CUPS printer name are not properly displayed. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139216 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.00/ >>>>> >>>>> It was found that the printer "?bc" (with the German umlaut "?" >>>>> as the first character) is displayed as "%C3%A4bc" in printer name. >>>>> Fixed to use the UTF-8 charset to decode the printer name. >>>>> >>>>> I could not add any test because it involves adding printer having >>>>> unicode character like "lpadmin -p "?bc" -v >>>>> http://example.org/printer3 -E" >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> > From prasanta.sadhukhan at oracle.com Mon Nov 2 08:41:15 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 2 Nov 2015 14:11:15 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <56327478.1060105@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> Message-ID: <563721AB.90407@oracle.com> Hi Phil, I have modified as per your review to populate GlyphInfo with "empty" glyph and also moved your existing test to "open" I also added a Infinite Transform test along with your NaN transform just incase (in fact Sergey informally asked me to check) http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ Regards Prasanta On 10/30/2015 1:03 AM, Phil Race wrote: > Should this new check go before this : > > CGGI_ClearCanvas(canvas, info); > > since it is using info which is where you get NaN from. > > > And should we then populate the returned canvas and info to > ensure that we return an "empty" glyph rather than garbage values ? > It is not clear to me that this is occurring. > > Why does the bug report not contain the evaluation below ? > Also why is there a new test ? I would expect SQE would > want to run the existing test to verify this fix. > Should we not just open the existing test ? > > > -phil. > > On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >> Gentle reminder for review >> >> Regards >> Prasanta >> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>> Hello All, >>> >>> Please review a fix for jdk9 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>> >>> drawString takes long time in mac native call >>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>> translated to x & y being NaN. >>> Fix is to prevent calling mac api for such invalid usage. >>> >>> Regards >>> Prasanta >> > From alexander.zvegintsev at oracle.com Mon Nov 2 13:17:15 2015 From: alexander.zvegintsev at oracle.com (Alexander Zvegintsev) Date: Mon, 2 Nov 2015 16:17:15 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8020448: Test closed/java/awt/font/JNICheck/JNICheck.sh fails on Solaris 11 In-Reply-To: <5631E19A.7040105@oracle.com> References: <5631E19A.7040105@oracle.com> Message-ID: <5637625B.9040509@oracle.com> Looks good to me. Thanks, Alexander. On 10/29/2015 12:06 PM, prasanta sadhukhan wrote: > Hi All, > > Please review a small fix in jdk9 whereby JNICheck issued a warning > that Exception is not checked after calling a JNI method. > This is in continuation to JDK-8130507 > fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8020448 > webrev: http://cr.openjdk.java.net/~psadhukhan/8020448/webrev.00/ > > It was seen that JNICheck was issuing a warning > WARNING in native method: JNI call made without checking exceptions > when required to from CallBooleanMethod > at sun.awt.FcFontManager.getFontPathNative(Native Method) > resulting in failure of this test. > There is another warning raised which is in core-libs code and a bug > has been raised against it 8131136 > > > Fix is to add the proper Exception check. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Mon Nov 2 14:57:22 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Mon, 02 Nov 2015 17:57:22 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR: JDK-8132890: Text overlapping on dot matrix printers. Message-ID: <563779D2.3000502@oracle.com> Hi All, Please review a backport of: https://bugs.openjdk.java.net/browse/JDK-8132890 to JDK8. The fix is the same, but the test was moved from closed part to open, so it's required to be reviewed. Webrev: http://cr.openjdk.java.net/~mcherkas/8132890/webrev.00/ jdk9 changeset: http://hg.openjdk.java.net/jdk9/client/jdk/rev/edec0fe63ceb Thanks, Mikhail. From prasanta.sadhukhan at oracle.com Tue Nov 3 08:59:19 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 3 Nov 2015 14:29:19 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. Message-ID: <56387767.7060101@oracle.com> Hi All, Please review a fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ The issue was if we "cancel" Printer Job setup dialog which has been created with DialogSelectionType.NATIVE it should return "null" as per spec https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- /[If the user cancels the dialog, the attributes will not reflect any changes made by the user, and the return value will be null.] /We were returning PageFormat instead. Fixed to return null in such case. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Nov 3 09:00:51 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 3 Nov 2015 14:30:51 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8139216: Non-ASCII characters in CUPS printer names are not properly displayed In-Reply-To: <5636F59A.4090602@oracle.com> References: <561F8411.9000806@oracle.com> <562DCEA0.3040605@oracle.com> <56326D8C.5080406@oracle.com> <5632FDED.6040106@oracle.com> <5633B264.2000509@oracle.com> <5636F59A.4090602@oracle.com> Message-ID: <563877C3.4050202@oracle.com> @Rajeev, could you please review and approve it? Regards Prasanta On 11/2/2015 11:03 AM, prasanta sadhukhan wrote: > Thanks Phil. > I need +1 for this. @Sergey, could you please review and approve it? > > Regards > Prasanta > On 10/30/2015 11:39 PM, Phil Race wrote: >> Ok .. approved. >> >> -phil. >> >> On 10/29/2015 10:19 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 10/30/2015 12:33 AM, Phil Race wrote: >>>> On 10/25/2015 11:56 PM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> I have modified the fix to assign printer name in case >>>>> UnsupportedEncodingException is thrown which is unlikely as we are >>>>> using UTF-8 as character encoding and not any user-supplied encoding. >>>>> http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.01/ >>>> >>>> It should be impossible as it would contradict the SE spec to not >>>> support UTF-8 >>>> https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset.html >>>> >>>> >>>> Anyway, off-list you said that even with this change you could not >>>> then >>>> open a connection because URLConnection was throwing an >>>> IOException. Is that somehow resolved ?? >>>> >>> I was trying a different approach that time which was causing that >>> problem. This fix does not have that problem and works. >>> >>> Regards >>> Prasanta >>>> -phil. >>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/15/2015 4:16 PM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for jdk9 where it was found that non-ASCII >>>>>> characters in CUPS printer name are not properly displayed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139216 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.00/ >>>>>> >>>>>> It was found that the printer "?bc" (with the German umlaut "?" >>>>>> as the first character) is displayed as "%C3%A4bc" in printer name. >>>>>> Fixed to use the UTF-8 charset to decode the printer name. >>>>>> >>>>>> I could not add any test because it involves adding printer >>>>>> having unicode character like "lpadmin -p "?bc" -v >>>>>> http://example.org/printer3 -E" >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> >> > From prasanta.sadhukhan at oracle.com Tue Nov 3 10:27:23 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 3 Nov 2015 15:57:23 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7161283: [macosx]filedialog didn't pop up for awt test InvalidParametersNativeTest In-Reply-To: <562E0067.7060408@oracle.com> References: <561766F4.7070708@oracle.com> <561CEF9A.9090600@oracle.com> <562E0067.7060408@oracle.com> Message-ID: <56388C0B.9030904@oracle.com> @Rajeev, Phil...please review. Regards Prasanta On 10/26/2015 3:58 PM, prasanta sadhukhan wrote: > Gentle reminder for review > > On 10/13/2015 5:18 PM, prasanta sadhukhan wrote: >> Gentle reminder for review. >> >> Regards >> Prasanta >> On 10/9/2015 12:34 PM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-7161283 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/7161283/webrev.00/ >>> >>> The bug mentioned that FileDialog is not shown when "Print" button >>> in applet is pressed (when "Print to File" is being tested) where >>> "ok/save" option will be shown. >>> But in standard Apple printer dialog there is no "Print to File" >>> option so this filedialog cannot be seen. Rather there is a "PDF" >>> option which allows to save the file, so the instructions should be >>> changed in the test for Mac. >>> >>> However, while investigating this problem, I found that there is a >>> NPE when no printer is added to the system so >>> PrinterJob.getPrintService() returns null but copyAttributes() uses >>> this printService object to check supported category attributes >>> without checking if the object is null or not. Added the relevant >>> check in PrintJob. >>> >>> Regards >>> Prasanta >> > From rajeev.chamyal at oracle.com Tue Nov 3 10:41:02 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 3 Nov 2015 02:41:02 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8139216: Non-ASCII characters in CUPS printer names are not properly displayed In-Reply-To: <563877C3.4050202@oracle.com> References: <561F8411.9000806@oracle.com> <562DCEA0.3040605@oracle.com> <56326D8C.5080406@oracle.com> <5632FDED.6040106@oracle.com> <5633B264.2000509@oracle.com> <5636F59A.4090602@oracle.com> <563877C3.4050202@oracle.com> Message-ID: Looks fine to me. Regards, Rajeev Chamyal -----Original Message----- From: prasanta sadhukhan Sent: 03 November 2015 14:31 To: Rajeev Chamyal; Phil Race Cc: 2d-dev at openjdk.java.net Subject: Re: [OpenJDK 2D-Dev] [9] RFR: JDK-8139216: Non-ASCII characters in CUPS printer names are not properly displayed @Rajeev, could you please review and approve it? Regards Prasanta On 11/2/2015 11:03 AM, prasanta sadhukhan wrote: > Thanks Phil. > I need +1 for this. @Sergey, could you please review and approve it? > > Regards > Prasanta > On 10/30/2015 11:39 PM, Phil Race wrote: >> Ok .. approved. >> >> -phil. >> >> On 10/29/2015 10:19 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 10/30/2015 12:33 AM, Phil Race wrote: >>>> On 10/25/2015 11:56 PM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> I have modified the fix to assign printer name in case >>>>> UnsupportedEncodingException is thrown which is unlikely as we are >>>>> using UTF-8 as character encoding and not any user-supplied encoding. >>>>> http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.01/ >>>> >>>> It should be impossible as it would contradict the SE spec to not >>>> support UTF-8 >>>> https://docs.oracle.com/javase/8/docs/api/java/nio/charset/Charset. >>>> html >>>> >>>> >>>> Anyway, off-list you said that even with this change you could not >>>> then open a connection because URLConnection was throwing an >>>> IOException. Is that somehow resolved ?? >>>> >>> I was trying a different approach that time which was causing that >>> problem. This fix does not have that problem and works. >>> >>> Regards >>> Prasanta >>>> -phil. >>>> >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/15/2015 4:16 PM, prasanta sadhukhan wrote: >>>>>> Hi All, >>>>>> >>>>>> Please review a fix for jdk9 where it was found that non-ASCII >>>>>> characters in CUPS printer name are not properly displayed. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8139216 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8139216/webrev.00/ >>>>>> >>>>>> It was found that the printer "?bc" (with the German umlaut "?" >>>>>> as the first character) is displayed as "%C3%A4bc" in printer name. >>>>>> Fixed to use the UTF-8 charset to decode the printer name. >>>>>> >>>>>> I could not add any test because it involves adding printer >>>>>> having unicode character like "lpadmin -p "?bc" -v >>>>>> http://example.org/printer3 -E" >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> >> > From rajeev.chamyal at oracle.com Wed Nov 4 09:11:33 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 4 Nov 2015 01:11:33 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8020448: Test closed/java/awt/font/JNICheck/JNICheck.sh fails on Solaris 11 In-Reply-To: <563998B0.5010305@oracle.com> References: <5637625B.9040509@oracle.com> <563998B0.5010305@oracle.com> Message-ID: <667d63f4-4803-4085-9077-790509fcfdd3@default> Looks ok to me. ? Regards, Rajeev Chamyal ? Subject: Re: [9] RFR: JDK-8020448: Test closed/java/awt/font/JNICheck/JNICheck.sh fails on Solaris 11 Date: Mon, 2 Nov 2015 16:17:15 +0300 From: Alexander Zvegintsev HYPERLINK "mailto:alexander.zvegintsev at oracle.com" To: prasanta sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com", HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net HYPERLINK "mailto:2d-dev at openjdk.java.net"<2d-dev at openjdk.java.net>, Phil Race HYPERLINK "mailto:philip.race at oracle.com" Looks good to me. Thanks, ? Alexander. On 10/29/2015 12:06 PM, prasanta sadhukhan wrote: Hi All, Please review a small fix in jdk9 whereby JNICheck issued a warning that Exception is not checked after calling a JNI method. This is in continuation to HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8130507"JDK-8130507 fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8020448 webrev: HYPERLINK "http://cr.openjdk.java.net/%7Epsadhukhan/8020448/webrev.00/"http://cr.openjdk.java.net/~psadhukhan/8020448/webrev.00/ It was seen that JNICheck was issuing a warning WARNING in native method: JNI call made without checking exceptions when required to from CallBooleanMethod ??????? at sun.awt.FcFontManager.getFontPathNative(Native Method) resulting in failure of this test. There is another warning raised which is in core-libs code and a bug has been raised against it HYPERLINK "https://bugs.openjdk.java.net/browse/JDK-8131136"8131136 Fix is to add the proper Exception check. Regards Prasanta ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Wed Nov 4 23:24:40 2015 From: philip.race at oracle.com (Philip Race) Date: Wed, 04 Nov 2015 15:24:40 -0800 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <563721AB.90407@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> <563721AB.90407@oracle.com> Message-ID: <563A93B8.1010202@oracle.com> This does not look right to me. Who knows what data is on the canvas ? it is not clear that it is 'blank'. It could have data from a previous glyph .. I am not sure how you know for sure. I can see that canvas is re-used. There is reference to a "global shared canvas". And the actual function you invoke is one of two : one for grey and one for lcd and looking at the grey one CGGI_CopyImageFromCanvasToAlphaInfo) it utilises info->width and info->height which can't be NaN because they are uint16 but I don't know if they are valid .. and is the "image" field allocated to be 0 length ? Could you step through how this is all guaranteed to be safe/correct ? -phil. On 11/2/15, 12:41 AM, prasanta sadhukhan wrote: > Hi Phil, > > I have modified as per your review to populate GlyphInfo with "empty" > glyph > and also moved your existing test to "open" > I also added a Infinite Transform test along with your NaN transform > just incase (in fact Sergey informally asked me to check) > > http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ > > Regards > Prasanta > On 10/30/2015 1:03 AM, Phil Race wrote: >> Should this new check go before this : >> >> CGGI_ClearCanvas(canvas, info); >> >> since it is using info which is where you get NaN from. >> >> >> And should we then populate the returned canvas and info to >> ensure that we return an "empty" glyph rather than garbage values ? >> It is not clear to me that this is occurring. >> >> Why does the bug report not contain the evaluation below ? >> Also why is there a new test ? I would expect SQE would >> want to run the existing test to verify this fix. >> Should we not just open the existing test ? >> >> >> -phil. >> >> On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >>> Gentle reminder for review >>> >>> Regards >>> Prasanta >>> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>>> Hello All, >>>> >>>> Please review a fix for jdk9 >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>>> >>>> drawString takes long time in mac native call >>>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>>> translated to x & y being NaN. >>>> Fix is to prevent calling mac api for such invalid usage. >>>> >>>> Regards >>>> Prasanta >>> >> > From Sergey.Bylokhov at oracle.com Thu Nov 5 09:59:32 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 5 Nov 2015 12:59:32 +0300 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7161283: [macosx]filedialog didn't pop up for awt test InvalidParametersNativeTest In-Reply-To: <561766F4.7070708@oracle.com> References: <561766F4.7070708@oracle.com> Message-ID: <563B2884.1080804@oracle.com> The fix looks fine to me. On 09.10.15 10:04, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9 > > Bug: https://bugs.openjdk.java.net/browse/JDK-7161283 > webrev: http://cr.openjdk.java.net/~psadhukhan/7161283/webrev.00/ > > The bug mentioned that FileDialog is not shown when "Print" button in > applet is pressed (when "Print to File" is being tested) where "ok/save" > option will be shown. > But in standard Apple printer dialog there is no "Print to File" option > so this filedialog cannot be seen. Rather there is a "PDF" option which > allows to save the file, so the instructions should be changed in the > test for Mac. > > However, while investigating this problem, I found that there is a NPE > when no printer is added to the system so PrinterJob.getPrintService() > returns null but copyAttributes() uses this printService object to check > supported category attributes without checking if the object is null or > not. Added the relevant check in PrintJob. > > Regards > Prasanta -- Best regards, Sergey. From alexandr.scherbatiy at oracle.com Thu Nov 5 10:50:06 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Thu, 05 Nov 2015 13:50:06 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <56297F04.1070606@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <56297F04.1070606@oracle.com> Message-ID: <563B345E.4010900@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8073320/webrev.03/ See my comments inline: On 10/23/2015 3:27 AM, Jim Graham wrote: > I only read the code portions I commented on below and the ones you > indicated you had changed. I'm assuming there are no other code > changes in this webrev...? > > This is getting really close to final which is good since I'll be > talking about this in my JavaOne talk next week... ;) > > In SG2D.scaleImage - the branch that uses transformImage uses the raw > transform which is expecting to transform an unscaled image. You'll > need to modify the transform accordingly so the result doesn't end up > double-sized. I reverted the changes back for the VolatileImage because it returns width and height of the original image, not the scaled ones. I added the xform transform rescaling for the MultiresolutionImage. > > BIGC, line 73 - shouldn't you pass in scaleX,scaleY to the constructor? Updated. > > Win32GD.c, lines 90,91 - I don't think I was clear below - is there a > need to have these initialized inline here with "= 1.0f" when they are > initialized in the constructor anyway? Are we worried that they'll be > accessed before the initScaleFactors() call can set them to > appropriate values (in which case we should then be worried that > they'll be the hard-coded 1.0 value instead of the "real" value)? It requires additional 'else' branch for the case when UI scales are disabled by user properties. I have updated this. > > Win32GD.c - I think I'm going to add an optional "x" to the scale > factors in JavaFX for completeness. Thus: > scale=Ndpi means scale factor of N/96 > scale=N% means scale factor of N/100 > scale=N.Mx means scale factor of N.M > scale=N.M also means scale factor of N.M (x is implicitly assumed) > The reason for this is both to have an explicit token for the regular > scale factor and also so that this matches with the default image > suffix of "@2x" so that we can add more ways to provide alternate > media such as "@120dpi" which are consistent with the values we use here. Updated. Thanks, Alexandr. > > BTW, we need to discuss ways to automate loading alternate media > beyond @2x at some point... > > ...jim > > On 10/21/15 6:34 AM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8073320/webrev.01/ >> >> - xform is concatenated with transform in SG2D.getResolutionVariant() >> method >> - imagepipe.transformImage() is used for drawImage(Image, >> AffineTransform,...) case >> - scale factors are made final in BufImgSurfaceData >> - two arrays are used for configs caching in BIGC >> - scale factors intialized from properties are moved to the static >> block in Win32GD >> >> On 10/10/2015 3:14 AM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> Just 2 potential issues I found: >>> >>> SG2D.java - getResolutionVariant() doesn't take a transform so it >>> can't take into account the scaling in the transform handed to >>> drawImage(img, xform). We can leave that as a follow-on bug fix (it >>> won't do bad things, but it may not pick the best resolution source >>> image). >>> >>> WGLOffscreenSD (in WGLSD.java) - does peer.getBounds() cache the >>> bounds? >> >> No. peer.getBounds() directly calls targetComponent.getBounds() >> which returns a copy of original bounds. >> >> Thanks, >> Alexandr. >>> If so, then every time we call get bounds on the WGLWSD we will >>> permanently modify the peer's bounds. Would it be better to not make >>> the assumption and just make a protected copy here (perhaps with scale >>> != 1?). >>> WGLWindowSD - same comment >>> D3DWindowSD - same comment >>> GDIWindowSD - same comment >>> >>> The rest of these are tweaks and optimizations. >>> >>> BISD.java - why do you have default initializers for the scale fields? >>> (There are only 2 constructors to cover.) >>> >>> BIGC.java - [2][NUMTYPES] would involve a lot fewer objects than >>> [NUMTYPES][2]... >>> BIGC.java - Or... If we only have 2 variations of each type, why not >>> just have 2 static arrays instead of a double-indexed array? >>> int index = (scaleX && scaleY) ? 0 : 1; >>> becomes: >>> BIGC configarray = (scaleX && scaleY) ? standardArray : >>> scaledArray; >>> >>> SG2D.java - Another way of dealing with transform in scaleImage would >>> be to make a copy of the incoming transform and adjust it to match the >>> request, as in: >>> // You can probably assert that dxywh == 0,0,imgW,imgH, or: >>> AffineTransform renderTX; >>> if (dxywh == 0,0,imgW,imgH) { >>> renderTX = xform; >>> } else { >>> // Should never happen in practice... >>> AffineTransform renderTX = new AffineTransform(xform); >>> renderTX.translate(dx1, dy1); >>> renderTX.scale((dx2 - dx1) / imgW, (dy2 - dy1) / imgH); >>> } >>> double-nested-try { >>> imagepipe.transformImage(..., renderTX); >>> } catch (InvalidPipe...) {...} >>> It would be more code, though, since you'd have to have 2 sets of >>> "double-nested-try-catch(InvalidPipe)" blocks. >>> >>> Win32GD.java - is there a need to have static initializers for the >>> scale fields? >>> >>> I'll leave the native code review to someone more familiar with that >>> code base... >>> >>> ...jim >>> >>> On 9/22/15 2:33 AM, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073320 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 >>>> >>>> This is an initial part of the HiDPI Graphics support on Windows >>>> for >>>> the JEP 263: HiDPI Graphics on Windows and Linux >>>> http://openjdk.java.net/jeps/263 >>>> >>>> - scale factors are added to surface dates >>>> - window size, events coordinates and font are scaled on native >>>> side >>>> - backup buffered image is scaled in SunVolatileImage >>>> - AwtRobot MouseMove() and GetRGBPixels() methods are updated >>>> - GetDpiForMonitor function is used to query the specified monitor >>>> for the horizontal and vertical DPI values. >>>> If it is not available ID2D1Factory::GetDesktopDpi method is used >>>> instead. >>>> - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", >>>> "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are >>>> added for the testing purposes. >>>> >>>> Thanks, >>>> Alexandr. >>>> >> From jayathirth.d.v at oracle.com Thu Nov 5 11:55:29 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 5 Nov 2015 03:55:29 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Message-ID: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> Hello All, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 Webrev : http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ Bug : IndexOutOfBoundsException when drawing PNGs Root cause : When user intentionally throws IO Exception while write is happening. We call ios.finish() in finally block of write_IDAT() which internally goes to finishChunk(). But the startPos of the chunk is still pointing to present IDAT chunk but flushedPos(streamPos) is pointing to end of IDAT chunk. So in finishChunk(), startPos will be less than flushedPos. This is causing IndexOutOfBoundException in stream.seek() and cache is not closed. Solution : If IOException is thrown by user, catch the exception while write is happening and update startPos to streamPos. So that when seek() happens in finishChunk() we don't see IndexOutOfBoundsException and cache is closed properly. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Nov 6 07:49:11 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 6 Nov 2015 13:19:11 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <563A93B8.1010202@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> <563721AB.90407@oracle.com> <563A93B8.1010202@oracle.com> Message-ID: <563C5B77.2060607@oracle.com> Hi Phil, On 11/5/2015 4:54 AM, Philip Race wrote: > This does not look right to me. Who knows what data is on the canvas ? > it is not clear that it is 'blank'. It could have data from a previous > glyph .. I am not > sure how you know for sure. I can see that canvas is re-used. There is > reference > to a "global shared canvas". > And the actual function you invoke is one of two : one for grey and > one for lcd and > looking at the grey one CGGI_CopyImageFromCanvasToAlphaInfo) > it utilises info->width and info->height which can't be NaN because they > are uint16 but I don't know if they are valid .. and is the "image" field > allocated to be 0 length ? info->width & height is coming out to be 0 in case of NaN transform therefore "image" field will be of 0 length so "empty" glyph will be copied when we copy the "glyph image" from canvas (no matter what is there in canvas) to info->image via this code http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m#l294 size_t destRow = y * destRowWidth; size_t srcRow = y * srcRowWidth; size_t x; for (x = 0; x < destRowWidth; x++) { UInt32 p = src[srcRow + x]; dest[destRow + x] = CGGI_ConvertBWPixelToByteGray(p); where destRowWidth = destRow = info->width will be 0 so dest = info->image will be of 0 length Regards Prasanta > Could you step through how this is all guaranteed > to be safe/correct ? > > -phil. > > On 11/2/15, 12:41 AM, prasanta sadhukhan wrote: >> Hi Phil, >> >> I have modified as per your review to populate GlyphInfo with "empty" >> glyph >> and also moved your existing test to "open" >> I also added a Infinite Transform test along with your NaN transform >> just incase (in fact Sergey informally asked me to check) >> >> http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ >> >> Regards >> Prasanta >> On 10/30/2015 1:03 AM, Phil Race wrote: >>> Should this new check go before this : >>> >>> CGGI_ClearCanvas(canvas, info); >>> >>> since it is using info which is where you get NaN from. >>> >>> >>> And should we then populate the returned canvas and info to >>> ensure that we return an "empty" glyph rather than garbage values ? >>> It is not clear to me that this is occurring. >>> >>> Why does the bug report not contain the evaluation below ? >>> Also why is there a new test ? I would expect SQE would >>> want to run the existing test to verify this fix. >>> Should we not just open the existing test ? >>> >>> >>> -phil. >>> >>> On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >>>> Gentle reminder for review >>>> >>>> Regards >>>> Prasanta >>>> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>>>> Hello All, >>>>> >>>>> Please review a fix for jdk9 >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>>>> >>>>> drawString takes long time in mac native call >>>>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>>>> translated to x & y being NaN. >>>>> Fix is to prevent calling mac api for such invalid usage. >>>>> >>>>> Regards >>>>> Prasanta >>>> >>> >> From rajeev.chamyal at oracle.com Fri Nov 6 08:53:17 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Fri, 6 Nov 2015 00:53:17 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7161283: [macosx]filedialog didn't pop up for awt test InvalidParametersNativeTest In-Reply-To: <563B434F.8070208@oracle.com> References: <563B2884.1080804@oracle.com> <563B434F.8070208@oracle.com> Message-ID: <38fd1bf6-15cc-4ab3-b692-73e9bc9edda7@default> The fix looks good to me. ? Regards, Rajeev Chamyal Subject: Re: [9] RFR JDK-7161283: [macosx]filedialog didn't pop up for awt test InvalidParametersNativeTest Date: Thu, 5 Nov 2015 12:59:32 +0300 From: Sergey Bylokhov HYPERLINK "mailto:Sergey.Bylokhov at oracle.com" To: prasanta sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com", HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net HYPERLINK "mailto:2d-dev at openjdk.java.net"<2d-dev at openjdk.java.net>, Alexander HYPERLINK "mailto:alexandr.scherbatiy at oracle.com" ? The fix looks fine to me. ? On 09.10.15 10:04, prasanta sadhukhan wrote: > Hi All, >? > Please review a fix for jdk9 >? > Bug: https://bugs.openjdk.java.net/browse/JDK-7161283 > webrev: http://cr.openjdk.java.net/~psadhukhan/7161283/webrev.00/ >? > The bug mentioned that FileDialog is not shown when "Print" button in > applet is pressed (when "Print to File" is being tested) where "ok/save" > option will be shown. > But in standard Apple printer dialog there is no "Print to File" option > so this filedialog cannot be seen. Rather there is a "PDF" option which > allows to save the file, so the instructions should be changed in the > test for Mac. >? > However, while investigating this problem, I found that there is a NPE > when no printer is added to the system so PrinterJob.getPrintService() > returns null but copyAttributes() uses this printService object to check > supported category attributes without checking if the object is null or > not. Added the relevant check in PrintJob. >? > Regards > Prasanta ? ? -- Best regards, Sergey. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Nov 6 09:15:27 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 6 Nov 2015 14:45:27 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> Message-ID: <563C6FAF.3040600@oracle.com> Hi Jay, looks ok but I guess you need to do the same for finish() method too in similar way you did for finishChunk() as finish() is called from write_IHDR, write_CHRM etc and it calls flushBefore(). Also, I guess you should not consume IOB Exception and let it be thrown to user instead of RuntimeException after catching IOBE. Regards Prasanta On 11/5/2015 5:25 PM, Jayathirth D V wrote: > > Hello All, > > Please review following fix in jdk9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 > > Webrev : http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ > > Bug : IndexOutOfBoundsException when drawing PNGs > > Root cause : When user intentionally throws IO Exception while write > is happening. > We call ios.finish() in finally block of > write_IDAT() which internally goes to finishChunk(). But the startPos > of the chunk is still pointing to present IDAT chunk but > flushedPos(streamPos) is pointing to end of IDAT chunk. > So in finishChunk(), startPos will be less > than flushedPos. This is causing IndexOutOfBoundException in > stream.seek() and cache is not closed. > > Solution : If IOException is thrown by user, catch the exception while > write is happening and update startPos to streamPos. So that when > seek() happens in finishChunk() we don?t see IndexOutOfBoundsException > and cache is closed properly. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.hegarty at oracle.com Fri Nov 6 09:19:01 2015 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 6 Nov 2015 09:19:01 +0000 Subject: [OpenJDK 2D-Dev] Fwd: RFR [9] 8140606: Update library code to use internal Unsafe References: Message-ID: <344C92CE-0AC4-4FB1-AE21-3664CD445AB0@oracle.com> Forwarding to additional area specific mailing lists, as there are changes in the webrev that affect their area. -Chris. Begin forwarded message: > From: Chris Hegarty > Subject: RFR [9] 8140606: Update library code to use internal Unsafe > Date: 28 October 2015 19:55:41 GMT > To: "core-libs-dev at openjdk.java.net Libs" > > Following on from 8139891 "Prepare Unsafe for true encapsulation? [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > > This will be pushed to jdk9/dev once 8139891 makes its way from > hs-rt. > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8139891 From alexandr.scherbatiy at oracle.com Fri Nov 6 10:00:17 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 06 Nov 2015 13:00:17 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <5629BDA8.8080909@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> Message-ID: <563C7A31.6040100@oracle.com> Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ - pixbuf is freed in the awt_Robot.c - screenWidth/Height is rescaled in the XToolkit.initScreenSize() method See more comments inline: On 10/23/2015 7:55 AM, Jim Graham wrote: > On 10/22/2015 5:07 PM, Jim Graham wrote: >> I'm guessing that 6356322 has been fixed? Yes. >> >> In XComponentPeer we shouldn't be scaling a region, we should have >> created the region in a scaled coordinate system... Could you give more details on this? For example, we create a frame which is twice bigger than the original one for the scale 2. For this case it needs to scale the shape twice. The lox, loy, hix, hiy values are calculated correctly. The native function XShapeCombineRectangles is used to draw the final shape for the given window. >> >> In XDragSourceContextPeer, should the scaledown try to do rounding? >> Also, XMouseInfoPeer, lines 71,72? >> Also, XToolkit, lines 725,726,855-858? >> Also, XlibUtil, lines 129-131,159? >> Also, X11GraphicsConfig, line 272? I changed this to use scaleDown(x, scale) method from the XlibUtil. However, I am not sure about rounding. Only integer scale values can be used. In this case x / 2 (3, 4, ...) returns a rounding to the smallest value which is what we probably need. >> >> awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it might be >> used to compensate for fonts on HiDPI screens that are already scaled >> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the >> fonts. I'm not entirely sure I understand that, though, but it bares >> further investigation... > > https://bugs.openjdk.java.net/browse/JDK-8058742 > > may be related to this GDK_DPI_SCALE issue... I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix to rescale GTK L&F UI sizes so they look in the same way as other L&Fs. And the GDK_SCALE is used in the current fix to scale all UI. It looks like there is no need to use the GDK_DPI_SCALE in the current fix and I would prefer to not mix the current fix with the JDK-8058742. > > ...jim > >> Also, is GDK_SCALE the only platform scale factor that Linux/X11 >> might use? I used only GDK_SCALE in this fix. If there is another scale factors it would be better to add them in another fix. >> >> awt_Robot.c, line 280 - you lose the pointer to the old pixbuf, but >> shouldn't both be freed? I have updated this. >> awt_Robot.c, just verifying what I'm seeing - that if GTK operations >> fail then we use nearest neighbor scaling in the X11 backup code, right? Yes. >> >> gtk2_interface.h - isn't that a fragile connection to the gtk library to >> declare our own enum and assume that the compilers will use the same >> values? That is what gtk2_interface.h does for all enums to avoid explicit dependencies to the GTK lib. If there is a better solution, it can be considered in a separate fix. Thanks, Alexandr. >> >> ...jim >> >> On 10/22/15 7:03 AM, Alexander Scherbatiy wrote: >>> On 10/10/2015 3:16 AM, Jim Graham wrote: >>>> Hi Alexandr, >>>> >>>> Is it possible to create a diff of this without the fixes from 8073320 >>>> mixed in? This bug is really just focused on the Linux support of >>>> that other framework, right? >>> Here is the webrev which contains only the Linux changes: >>> http://cr.openjdk.java.net/~alexsch/8137571/webrev.01 >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> ...jim >>>> >>>> On 10/5/15 7:01 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8137571 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8137571/webrev.00 >>>>> >>>>> This is an initial part of the HiDPI Graphics support on Linux for >>>>> the JEP 263: HiDPI Graphics on Windows and Linux >>>>> http://openjdk.java.net/jeps/263 >>>>> >>>>> - scale factors are added to surface dates >>>>> - window size and events coordinates are scaled on peer side >>>>> - XRobotPeer mouseMove() and getRGBPixel() methods are updated >>>>> - GDK_SCALE system variable is used to detect the scale factor in >>>>> GTK+ >>>>> - "sun.java2d.uiScale.enabled", and "sun.java2d.uiScale" >>>>> options are >>>>> added for the testing purposes >>>>> - some classes like LWWindowPeer, SurfaceManager, SunGraphics2D, >>>>> DrawImage, SurfaceData are just the same as in the fix for HiDPI >>>>> Graphics support on Windows >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>> From jayathirth.d.v at oracle.com Fri Nov 6 10:20:41 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Fri, 6 Nov 2015 02:20:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <563C6FAF.3040600@oracle.com> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> Message-ID: <48666932-8fbd-4588-9175-07acdd24d78b@default> Hi Prasanta, As discussed, only in case of write_IDAT there is finally block which calls ios.finish() which internally calls seek() with improper startPos. In other cases we are not trying to access improper startPos because there is no call to ios.finish(). We can verify this behavior by changing logic where we throw IOException in test case. And I have modified test to not catch IOBE as per your suggestion. Please find updated Webrev link: http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ Thanks, Jay From: prasanta sadhukhan Sent: Friday, November 06, 2015 2:45 PM To: Jayathirth D V; 2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Hi Jay, looks ok but I guess you need to do the same for finish() method too in similar way you did for finishChunk() as finish() is called from write_IHDR, write_CHRM etc and it calls flushBefore(). Also, I guess you should not consume IOB Exception and let it be thrown to user instead of RuntimeException after catching IOBE. Regards Prasanta On 11/5/2015 5:25 PM, Jayathirth D V wrote: Hello All, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 Webrev : http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ Bug : IndexOutOfBoundsException when drawing PNGs Root cause : When user intentionally throws IO Exception while write is happening. We call ios.finish() in finally block of write_IDAT() which internally goes to finishChunk(). But the startPos of the chunk is still pointing to present IDAT chunk but flushedPos(streamPos) is pointing to end of IDAT chunk. So in finishChunk(), startPos will be less than flushedPos. This is causing IndexOutOfBoundException in stream.seek() and cache is not closed. Solution : If IOException is thrown by user, catch the exception while write is happening and update startPos to streamPos. So that when seek() happens in finishChunk() we don't see IndexOutOfBoundsException and cache is closed properly. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Nov 6 11:00:42 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 6 Nov 2015 16:30:42 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8039412, , Stack overflow on Linux using DialogTypeSelection.NATIVE Message-ID: <563C885A.7080009@oracle.com> Hi All, Please review a fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8039412 webrev: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.00/ Issue was seen in linux whereby if we call PrinterJob.pageDialog() after PrinterJob.printDialog() it results in StackOverflowError if DialogSelectionType is NATIVE. This was because pageDialog(attributes) was calling pageDialog(pageformat) if it is DialogTypeSelection.NATIVE which again calls pageDialog(attributes) via this code http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l767 and http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l743 I added a fix whereby in pageDialog(attributes)we check if it is DialogTypeSelection.NATIVE and remove this attribute temporarily before calling pageDialog(pageformat) and restore the DialogTypeSelection.NATIVE after the call. It is similar to solution done in http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l443 Regards Prasanta From james.graham at oracle.com Sat Nov 7 00:56:01 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 6 Nov 2015 16:56:01 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <563C7A31.6040100@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> <563C7A31.6040100@oracle.com> Message-ID: <563D4C21.2000103@oracle.com> It looks like the only remaining issues are: - Should we scale the origin of the screens so that they remain adjacent? Questions that remain and may end up getting handled under followon bugs: - We should really think through rounding issues better in scaleDown() - We need to see if there can be a more accurate way to handle applyShape(Region) at the device scale. - DPI_SCALE needs to be handled eventually, don't let it fall through the cracks - Other Linux DPI attributes should be handled, hopefully there is a bug filed for that Some of those could be simply left for feedback from developers, but what is our plan to get our developers to do a decent amount of testing with their applications to let us know if our choices were fine? More comments inline below: On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ > > - pixbuf is freed in the awt_Robot.c > - screenWidth/Height is rescaled in the XToolkit.initScreenSize() method Is there also a position that needs to be adjusted? Is the convention that all screens should be directly adjacent, or can they float with gaps between them? > See more comments inline: > >>> In XComponentPeer we shouldn't be scaling a region, we should have >>> created the region in a scaled coordinate system... > > Could you give more details on this? > For example, we create a frame which is twice bigger than the > original one for the scale 2. > For this case it needs to scale the shape twice. The lox, loy, > hix, hiy values are calculated correctly. > The native function XShapeCombineRectangles is used to draw the > final shape for the given window. I suppose it may be architecturally difficult to do at this point, but ideally a Region should be a create-only structure that is produced at the desired device coordinate system and scaling. It might be necessary to perform integer translates on it as windows are moved around the screen from one integer location to another, but it should never be scaled. The fact that there is a method that can scale a region is basically an admission that we have not always done the right thing with respect to creating regions at device resolution. It looks like this may be the path of least resistance currently, but if we can improve the architecture to allow the Region to maintain full device resolution and not require any scaling that would be far better. >>> In XDragSourceContextPeer, should the scaledown try to do rounding? >>> Also, XMouseInfoPeer, lines 71,72? >>> Also, XToolkit, lines 725,726,855-858? >>> Also, XlibUtil, lines 129-131,159? >>> Also, X11GraphicsConfig, line 272? > I changed this to use scaleDown(x, scale) method from the XlibUtil. > However, I am not sure about rounding. Only integer scale values > can be used. In this case x / 2 (3, 4, ...) returns a rounding to the > smallest value > which is what we probably need. The fact that only integer scaling values can be used only makes scaling up easier. It still begs the question of what value to report when we end up with X.5 or X.75 - should that be X or X+1? Why is truncation/rounding down what we need? Where is the analysis of how application behavior will be affected by rounding down vs. rounding up or rounding evenly? Note that in FX we have a number of different coordinate snapping functions that perform different rounding operations. Some are for sizes of things, some are for locations, and some are for calculating distributed distances during layout. >>> awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it might be >>> used to compensate for fonts on HiDPI screens that are already scaled >>> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the >>> fonts. I'm not entirely sure I understand that, though, but it bares >>> further investigation... >> >> https://bugs.openjdk.java.net/browse/JDK-8058742 >> >> may be related to this GDK_DPI_SCALE issue... > I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix > to rescale GTK L&F UI sizes so they look in the same way as other L&Fs. > And the GDK_SCALE is used in the current fix to scale all UI. > It looks like there is no need to use the GDK_DPI_SCALE in the > current fix and I would prefer to not mix the current fix with the > JDK-8058742. OK, as long as we are aware of it and tracking it. It sounds like GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought that they'd be implemented as part of the same fix, but as long as we get to it sooner rather than later, that's fine. >>> Also, is GDK_SCALE the only platform scale factor that Linux/X11 >>> might use? > > I used only GDK_SCALE in this fix. If there is another scale > factors it would be better to add them in another fix. True. I included this link in my HiDPI talk which appears to be a fairly comprehensive list: https://wiki.archlinux.org/index.php/HiDPI ...jim From alexandr.scherbatiy at oracle.com Mon Nov 9 10:50:48 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 09 Nov 2015 13:50:48 +0300 Subject: [OpenJDK 2D-Dev] Duplicated (or better multiplicated) image-decoder resolvers in openjdk In-Reply-To: <563A1951.9020500@redhat.com> References: <56336CE6.2010106@redhat.com> <563A1951.9020500@redhat.com> Message-ID: <56407A88.2000805@oracle.com> Adding 2d-dev alias to the cc. Thanks, Alexandr. On 11/4/2015 5:42 PM, Jiri Vanek wrote: > ping? > > On 10/30/2015 02:13 PM, Jiri Vanek wrote: >> Hello! >> >> Recently I was doing ico imagereader-spi provider for icedtea-web >> (which is javaws (and plugin) >> implementation for openjdk) >> Yes, ico is stupid, but is in web standards so having its support is >> just natural. However, >> providing spi did not solved the problem i was bugged for. >> >> After small debugging why, I found that eg SunToolkit.createImage and >> relatives - which are quite >> heavily used, do not honour ImageIO SPIs and are going by its own way: >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/FileImageSource.java#l50 >> >> >> for file >> and >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/InputStreamImageSource.java#l213 >> >> >> for stream >> >> Well maybe its legacy bourden, but it is reimplementing what image >> SPIs providers via (apis >> canDecodeInput[2]) do. Long story short - reimplementing wheel and >> duplicated (very duplicated) code. >> >> I wonted to ask, if there are any plans in jdk9 to fix this. If no, >> what can I do to make it happen. >> >> >> Thanx! >> J. >> >> >> [2] >> https://docs.oracle.com/javase/7/docs/api/javax/imageio/spi/ImageReaderSpi.html#canDecodeInput%28java.lang.Object%29 >> >> >> https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageReader.html > From alexandr.scherbatiy at oracle.com Mon Nov 9 12:45:48 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 09 Nov 2015 15:45:48 +0300 Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <563DB869.80600@redhat.com> References: <563DB869.80600@redhat.com> Message-ID: <5640957C.10702@oracle.com> On 11/7/2015 11:38 AM, Jiri Vanek wrote: > Hello! > > Looking to imageIO.java (if this is bad thread, please redirect me!) 2d-dev alias should be also the right place to ask image related questions in AWT. Thanks, Alexandr. > when reading images > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 > > and ending at: > > // Perform mark/reset as a defensive measure > // even though plug-ins are supposed to take > // care of it. > boolean canDecode = false; > if (stream != null) { > stream.mark(); > } > canDecode = spi.canDecodeInput(input); > if (stream != null) { > stream.reset(); > } > return canDecode; > > I'm wondering, why stream.reset(); is not in finaly block: > > // Perform mark/reset as a defensive measure > // even though plug-ins are supposed to take > // care of it. > boolean canDecode = false; > if (stream != null) { > stream.mark(); > } > try{ > canDecode = spi.canDecodeInput(input); > } finally { > if (stream != null) { > stream.reset(); > } > } > return canDecode; > > > Eg png and bmp decoders can are throwing IIOException when header is > corrutped. That pretty definitely sure killer of stream mark stacks. > You yourselves write : //Perform mark/reset as a defensive measure > even though plug-ins are supposed to take care of it. > So if densive, then try/finaly please. > > I did not check if this changed in 9 but if not....Please. This is > makig work on custom image plugins, for image formats which just wraps > another bmp/png and are expecting corrupted headers preatty hards. > > > J. From alexandr.scherbatiy at oracle.com Tue Nov 10 13:07:27 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 10 Nov 2015 16:07:27 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <563D4C21.2000103@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> <563C7A31.6040100@oracle.com> <563D4C21.2000103@oracle.com> Message-ID: <5641EC0F.5060304@oracle.com> On 11/7/2015 3:56 AM, Jim Graham wrote: > It looks like the only remaining issues are: > > - Should we scale the origin of the screens so that they remain adjacent? The Toolkit defines only methods that allows to get size of the the primary screen and screen insets which are rescaled in the provided fix. The XGraphicsConfiguration bounds are also rescaled. > > Questions that remain and may end up getting handled under followon bugs: > > - We should really think through rounding issues better in scaleDown() > - We need to see if there can be a more accurate way to handle > applyShape(Region) at the device scale. > - DPI_SCALE needs to be handled eventually, don't let it fall through > the cracks > - Other Linux DPI attributes should be handled, hopefully there is a > bug filed for that > > Some of those could be simply left for feedback from developers, but > what is our plan to get our developers to do a decent amount of > testing with their applications to let us know if our choices were fine? > > More comments inline below: > > On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ >> >> - pixbuf is freed in the awt_Robot.c >> - screenWidth/Height is rescaled in the XToolkit.initScreenSize() >> method > > Is there also a position that needs to be adjusted? Is the convention > that all screens should be directly adjacent, or can they float with > gaps between them? The toolkit does not provide method to get the primary screen position. I thought about adjusting screens with different scaling but it looks like it is an additional task which can be handled in a separated bug. > >> See more comments inline: >> >>>> In XComponentPeer we shouldn't be scaling a region, we should have >>>> created the region in a scaled coordinate system... >> >> Could you give more details on this? >> For example, we create a frame which is twice bigger than the >> original one for the scale 2. >> For this case it needs to scale the shape twice. The lox, loy, >> hix, hiy values are calculated correctly. >> The native function XShapeCombineRectangles is used to draw the >> final shape for the given window. > > I suppose it may be architecturally difficult to do at this point, but > ideally a Region should be a create-only structure that is produced at > the desired device coordinate system and scaling. It might be > necessary to perform integer translates on it as windows are moved > around the screen from one integer location to another, but it should > never be scaled. The fact that there is a method that can scale a > region is basically an admission that we have not always done the > right thing with respect to creating regions at device resolution. > > It looks like this may be the path of least resistance currently, but > if we can improve the architecture to allow the Region to maintain > full device resolution and not require any scaling that would be far > better. I see now. > >>>> In XDragSourceContextPeer, should the scaledown try to do rounding? >>>> Also, XMouseInfoPeer, lines 71,72? >>>> Also, XToolkit, lines 725,726,855-858? >>>> Also, XlibUtil, lines 129-131,159? >>>> Also, X11GraphicsConfig, line 272? >> I changed this to use scaleDown(x, scale) method from the >> XlibUtil. >> However, I am not sure about rounding. Only integer scale values >> can be used. In this case x / 2 (3, 4, ...) returns a rounding to the >> smallest value >> which is what we probably need. > > The fact that only integer scaling values can be used only makes > scaling up easier. It still begs the question of what value to report > when we end up with X.5 or X.75 - should that be X or X+1? > > Why is truncation/rounding down what we need? Where is the analysis > of how application behavior will be affected by rounding down vs. > rounding up or rounding evenly? > > Note that in FX we have a number of different coordinate snapping > functions that perform different rounding operations. Some are for > sizes of things, some are for locations, and some are for calculating > distributed distances during layout. It could be better to move the question about location, sizes and distances scaling to a separate bug. The same question I also have for the Windows HiDPI Graphics support. Thanks, Alexandr. > >>>> awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it >>>> might be >>>> used to compensate for fonts on HiDPI screens that are already scaled >>>> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the >>>> fonts. I'm not entirely sure I understand that, though, but it bares >>>> further investigation... >>> >>> https://bugs.openjdk.java.net/browse/JDK-8058742 >>> >>> may be related to this GDK_DPI_SCALE issue... >> I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix >> to rescale GTK L&F UI sizes so they look in the same way as other L&Fs. >> And the GDK_SCALE is used in the current fix to scale all UI. >> It looks like there is no need to use the GDK_DPI_SCALE in the >> current fix and I would prefer to not mix the current fix with the >> JDK-8058742. > > OK, as long as we are aware of it and tracking it. It sounds like > GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought > that they'd be implemented as part of the same fix, but as long as we > get to it sooner rather than later, that's fine. > >>>> Also, is GDK_SCALE the only platform scale factor that Linux/X11 >>>> might use? >> >> I used only GDK_SCALE in this fix. If there is another scale >> factors it would be better to add them in another fix. > > True. I included this link in my HiDPI talk which appears to be a > fairly comprehensive list: > > https://wiki.archlinux.org/index.php/HiDPI > > ...jim From james.graham at oracle.com Tue Nov 10 19:26:59 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 10 Nov 2015 11:26:59 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <5641EC0F.5060304@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> <563C7A31.6040100@oracle.com> <563D4C21.2000103@oracle.com> <5641EC0F.5060304@oracle.com> Message-ID: <56424503.1050908@oracle.com> On 11/10/15 5:07 AM, Alexander Scherbatiy wrote: >> On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ >>> >>> - pixbuf is freed in the awt_Robot.c >>> - screenWidth/Height is rescaled in the XToolkit.initScreenSize() >>> method >> >> Is there also a position that needs to be adjusted? Is the convention >> that all screens should be directly adjacent, or can they float with >> gaps between them? > > The toolkit does not provide method to get the primary screen position. > I thought about adjusting screens with different scaling but it > looks like it is an additional task which can be handled in a separated > bug. True. In particular, I'm not sure how Linux deals with this, but I find that on Win 8.1 HiDPI the screen bounds we get from Windows are already non-adjacent in many mixed-DPI cases. > It could be better to move the question about location, sizes and > distances scaling to a separate bug. The same question I also have for > the Windows HiDPI Graphics support. That's also something that might be helped by getting this out there and getting feedback and test cases on where the current rounding might not do the best thing... ...jim From james.graham at oracle.com Tue Nov 10 19:31:37 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 10 Nov 2015 11:31:37 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <5641EC0F.5060304@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> <563C7A31.6040100@oracle.com> <563D4C21.2000103@oracle.com> <5641EC0F.5060304@oracle.com> Message-ID: <56424619.8090606@oracle.com> I think this can be good to go, but file some issues for further investigation: - scaling in applyShape() - GDK_DPI_SCALE (though it may get handled under the other bug, maybe add a comment there) - Other Linux DPI properties to support And while we probably don't need an issue submitted until we have a test case that shows trouble, we should plan some extensive internal testing of any apps we have on HiDPI monitors to see if they encounter rounding issues with coordinates. Areas that may show trouble would be apps that resize themselves, resizing apps with the window handles, scrolling. That's a "task", but not really an issue to file... ...jim On 11/10/15 5:07 AM, Alexander Scherbatiy wrote: > On 11/7/2015 3:56 AM, Jim Graham wrote: >> It looks like the only remaining issues are: >> >> - Should we scale the origin of the screens so that they remain adjacent? > > The Toolkit defines only methods that allows to get size of the the > primary screen and screen insets which are rescaled in the provided fix. > The XGraphicsConfiguration bounds are also rescaled. > >> >> Questions that remain and may end up getting handled under followon bugs: >> >> - We should really think through rounding issues better in scaleDown() >> - We need to see if there can be a more accurate way to handle >> applyShape(Region) at the device scale. >> - DPI_SCALE needs to be handled eventually, don't let it fall through >> the cracks >> - Other Linux DPI attributes should be handled, hopefully there is a >> bug filed for that >> >> Some of those could be simply left for feedback from developers, but >> what is our plan to get our developers to do a decent amount of >> testing with their applications to let us know if our choices were fine? >> >> More comments inline below: >> >> On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ >>> >>> - pixbuf is freed in the awt_Robot.c >>> - screenWidth/Height is rescaled in the XToolkit.initScreenSize() >>> method >> >> Is there also a position that needs to be adjusted? Is the convention >> that all screens should be directly adjacent, or can they float with >> gaps between them? > > The toolkit does not provide method to get the primary screen position. > I thought about adjusting screens with different scaling but it > looks like it is an additional task which can be handled in a separated > bug. >> >>> See more comments inline: >>> >>>>> In XComponentPeer we shouldn't be scaling a region, we should have >>>>> created the region in a scaled coordinate system... >>> >>> Could you give more details on this? >>> For example, we create a frame which is twice bigger than the >>> original one for the scale 2. >>> For this case it needs to scale the shape twice. The lox, loy, >>> hix, hiy values are calculated correctly. >>> The native function XShapeCombineRectangles is used to draw the >>> final shape for the given window. >> >> I suppose it may be architecturally difficult to do at this point, but >> ideally a Region should be a create-only structure that is produced at >> the desired device coordinate system and scaling. It might be >> necessary to perform integer translates on it as windows are moved >> around the screen from one integer location to another, but it should >> never be scaled. The fact that there is a method that can scale a >> region is basically an admission that we have not always done the >> right thing with respect to creating regions at device resolution. >> >> It looks like this may be the path of least resistance currently, but >> if we can improve the architecture to allow the Region to maintain >> full device resolution and not require any scaling that would be far >> better. > > I see now. >> >>>>> In XDragSourceContextPeer, should the scaledown try to do rounding? >>>>> Also, XMouseInfoPeer, lines 71,72? >>>>> Also, XToolkit, lines 725,726,855-858? >>>>> Also, XlibUtil, lines 129-131,159? >>>>> Also, X11GraphicsConfig, line 272? >>> I changed this to use scaleDown(x, scale) method from the >>> XlibUtil. >>> However, I am not sure about rounding. Only integer scale values >>> can be used. In this case x / 2 (3, 4, ...) returns a rounding to the >>> smallest value >>> which is what we probably need. >> >> The fact that only integer scaling values can be used only makes >> scaling up easier. It still begs the question of what value to report >> when we end up with X.5 or X.75 - should that be X or X+1? >> >> Why is truncation/rounding down what we need? Where is the analysis >> of how application behavior will be affected by rounding down vs. >> rounding up or rounding evenly? >> >> Note that in FX we have a number of different coordinate snapping >> functions that perform different rounding operations. Some are for >> sizes of things, some are for locations, and some are for calculating >> distributed distances during layout. > > It could be better to move the question about location, sizes and > distances scaling to a separate bug. The same question I also have for > the Windows HiDPI Graphics support. > > Thanks, > Alexandr. > >> >>>>> awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it >>>>> might be >>>>> used to compensate for fonts on HiDPI screens that are already scaled >>>>> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the >>>>> fonts. I'm not entirely sure I understand that, though, but it bares >>>>> further investigation... >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8058742 >>>> >>>> may be related to this GDK_DPI_SCALE issue... >>> I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix >>> to rescale GTK L&F UI sizes so they look in the same way as other L&Fs. >>> And the GDK_SCALE is used in the current fix to scale all UI. >>> It looks like there is no need to use the GDK_DPI_SCALE in the >>> current fix and I would prefer to not mix the current fix with the >>> JDK-8058742. >> >> OK, as long as we are aware of it and tracking it. It sounds like >> GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought >> that they'd be implemented as part of the same fix, but as long as we >> get to it sooner rather than later, that's fine. >> >>>>> Also, is GDK_SCALE the only platform scale factor that Linux/X11 >>>>> might use? >>> >>> I used only GDK_SCALE in this fix. If there is another scale >>> factors it would be better to add them in another fix. >> >> True. I included this link in my HiDPI talk which appears to be a >> fairly comprehensive list: >> >> https://wiki.archlinux.org/index.php/HiDPI >> >> ...jim > From james.graham at oracle.com Tue Nov 10 19:41:10 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 10 Nov 2015 11:41:10 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <562900B8.7060503@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> Message-ID: <56424856.3060007@oracle.com> In drawHiDPIImage, in the VolatileImage case you ignore the transform, but I suppose that is OK because you pass it through to the scaleImage() case. However if it came in with a transform then the asserts at the top of scaleImage may fail? Maybe it would be better to actually handle the "non-0,0,iw,ih" case rather than assert that it doesn't exist? BIGC.getConfig() - I don't see where you put the scale into the BIGC when you create it. Shouldn't the constructor with scales be used at line 73? SGE.getScaleFactor() - suggestion: perhaps ignore an optional final suffix "x" in the regular scale case so that they can say "=3.0x" to mean the same as "=3"? Looks almost good to go from my perspective. What is the plan for Swing testing and fixing those bugs? ...jim On 10/22/15 8:28 AM, Alexander Scherbatiy wrote: > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8073320/webrev.02/ > > > On 10/21/2015 5:40 PM, Sergey Bylokhov wrote: >> I have two small suggestions: >> - Probably it will be better to move the new properties from >> Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at least >> "sun.java2d.uiScale" should be implemented on linux, and can be >> implemented on osx later. > I have moved the uiScale properties initialization to the > SunGraphicsEnvironment and Win32GraphicsEnvironment classes. >> - I am worried about a rounding in >> awt_Win32GraphicsDevice.ScaleDownXY/ScaleUpXY when these methods are >> applied to the x/y and width/height. > > Could I move this update to a separate fix? > > Thanks, > Alexandr. > >> >> On 21.10.15 16:34, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.01/ >>> >>> - xform is concatenated with transform in SG2D.getResolutionVariant() >>> method >>> - imagepipe.transformImage() is used for drawImage(Image, >>> AffineTransform,...) case >>> - scale factors are made final in BufImgSurfaceData >>> - two arrays are used for configs caching in BIGC >>> - scale factors intialized from properties are moved to the static >>> block in Win32GD >>> >>> On 10/10/2015 3:14 AM, Jim Graham wrote: >>>> Hi Alexandr, >>>> >>>> Just 2 potential issues I found: >>>> >>>> SG2D.java - getResolutionVariant() doesn't take a transform so it >>>> can't take into account the scaling in the transform handed to >>>> drawImage(img, xform). We can leave that as a follow-on bug fix (it >>>> won't do bad things, but it may not pick the best resolution source >>>> image). >>>> >>>> WGLOffscreenSD (in WGLSD.java) - does peer.getBounds() cache the >>>> bounds? >>> >>> No. peer.getBounds() directly calls targetComponent.getBounds() >>> which returns a copy of original bounds. >>> >>> Thanks, >>> Alexandr. >>>> If so, then every time we call get bounds on the WGLWSD we will >>>> permanently modify the peer's bounds. Would it be better to not make >>>> the assumption and just make a protected copy here (perhaps with scale >>>> != 1?). >>>> WGLWindowSD - same comment >>>> D3DWindowSD - same comment >>>> GDIWindowSD - same comment >>>> >>>> The rest of these are tweaks and optimizations. >>>> >>>> BISD.java - why do you have default initializers for the scale fields? >>>> (There are only 2 constructors to cover.) >>>> >>>> BIGC.java - [2][NUMTYPES] would involve a lot fewer objects than >>>> [NUMTYPES][2]... >>>> BIGC.java - Or... If we only have 2 variations of each type, why not >>>> just have 2 static arrays instead of a double-indexed array? >>>> int index = (scaleX && scaleY) ? 0 : 1; >>>> becomes: >>>> BIGC configarray = (scaleX && scaleY) ? standardArray : >>>> scaledArray; >>>> >>>> SG2D.java - Another way of dealing with transform in scaleImage would >>>> be to make a copy of the incoming transform and adjust it to match the >>>> request, as in: >>>> // You can probably assert that dxywh == 0,0,imgW,imgH, or: >>>> AffineTransform renderTX; >>>> if (dxywh == 0,0,imgW,imgH) { >>>> renderTX = xform; >>>> } else { >>>> // Should never happen in practice... >>>> AffineTransform renderTX = new AffineTransform(xform); >>>> renderTX.translate(dx1, dy1); >>>> renderTX.scale((dx2 - dx1) / imgW, (dy2 - dy1) / imgH); >>>> } >>>> double-nested-try { >>>> imagepipe.transformImage(..., renderTX); >>>> } catch (InvalidPipe...) {...} >>>> It would be more code, though, since you'd have to have 2 sets of >>>> "double-nested-try-catch(InvalidPipe)" blocks. >>>> >>>> Win32GD.java - is there a need to have static initializers for the >>>> scale fields? >>>> >>>> I'll leave the native code review to someone more familiar with that >>>> code base... >>>> >>>> ...jim >>>> >>>> On 9/22/15 2:33 AM, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073320 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 >>>>> >>>>> This is an initial part of the HiDPI Graphics support on Windows >>>>> for >>>>> the JEP 263: HiDPI Graphics on Windows and Linux >>>>> http://openjdk.java.net/jeps/263 >>>>> >>>>> - scale factors are added to surface dates >>>>> - window size, events coordinates and font are scaled on native >>>>> side >>>>> - backup buffered image is scaled in SunVolatileImage >>>>> - AwtRobot MouseMove() and GetRGBPixels() methods are updated >>>>> - GetDpiForMonitor function is used to query the specified monitor >>>>> for the horizontal and vertical DPI values. >>>>> If it is not available ID2D1Factory::GetDesktopDpi method is used >>>>> instead. >>>>> - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", >>>>> "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are >>>>> added for the testing purposes. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>> >> >> > From prasanta.sadhukhan at oracle.com Wed Nov 11 06:43:26 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 11 Nov 2015 12:13:26 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <48666932-8fbd-4588-9175-07acdd24d78b@default> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> Message-ID: <5642E38E.5020406@oracle.com> Looks ok to me. Regards Prasanta On 11/6/2015 3:50 PM, Jayathirth D V wrote: > > Hi Prasanta, > > As discussed, only in case of write_IDAT there is finally block which > calls ios.finish() which internally calls seek() with improper > startPos. In other cases we are not trying to access improper startPos > because there is no call to ios.finish(). We can verify this behavior > by changing logic where we throw IOException in test case. > > And I have modified test to not catch IOBE as per your suggestion. > Please find updated Webrev link: > > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Friday, November 06, 2015 2:45 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > *Cc:* Philip Race > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Hi Jay, > > looks ok but > I guess you need to do the same for finish() method too in similar way > you did for finishChunk() as finish() is called from write_IHDR, > write_CHRM etc and it calls flushBefore(). > Also, I guess you should not consume IOB Exception and let it be > thrown to user instead of RuntimeException after catching IOBE. > > Regards > Prasanta > > On 11/5/2015 5:25 PM, Jayathirth D V wrote: > > Hello All, > > Please review following fix in jdk9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 > > Webrev : > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ > > > Bug : IndexOutOfBoundsException when drawing PNGs > > Root cause : When user intentionally throws IO Exception while > write is happening. > We call ios.finish() in finally block of > write_IDAT() which internally goes to finishChunk(). But the > startPos of the chunk is still pointing to present IDAT chunk but > flushedPos(streamPos) is pointing to end of IDAT chunk. > So in finishChunk(), startPos will be > less than flushedPos. This is causing IndexOutOfBoundException in > stream.seek() and cache is not closed. > > Solution : If IOException is thrown by user, catch the exception > while write is happening and update startPos to streamPos. So that > when seek() happens in finishChunk() we don?t see > IndexOutOfBoundsException and cache is closed properly. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikhail.cherkasov at oracle.com Wed Nov 11 10:03:04 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Wed, 11 Nov 2015 13:03:04 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR: JDK-8132890: Text overlapping on dot matrix printers. In-Reply-To: <563779D2.3000502@oracle.com> References: <563779D2.3000502@oracle.com> Message-ID: <56431258.7090304@oracle.com> Hi all, It's just kindly reminder about this review request. Thanks, Mikhail. On 11/2/2015 17:57, mikhail cherkasov wrote: > Hi All, > > Please review a backport of: > https://bugs.openjdk.java.net/browse/JDK-8132890 > to JDK8. > > The fix is the same, but the test was moved from closed part to open, > so it's required to be > reviewed. > > Webrev: > http://cr.openjdk.java.net/~mcherkas/8132890/webrev.00/ > > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/client/jdk/rev/edec0fe63ceb > > Thanks, > Mikhail. From alexandr.scherbatiy at oracle.com Wed Nov 11 11:08:48 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Wed, 11 Nov 2015 14:08:48 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <56424856.3060007@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> Message-ID: <564321C0.9030106@oracle.com> On 11/10/2015 10:41 PM, Jim Graham wrote: > In drawHiDPIImage, in the VolatileImage case you ignore the transform, > but I suppose that is OK because you pass it through to the > scaleImage() case. However if it came in with a transform then the > asserts at the top of scaleImage may fail? Maybe it would be better > to actually handle the "non-0,0,iw,ih" case rather than assert that it > doesn't exist? The only case where xform is not null is the drawImage(img, xform, observer) method which always use zero x, y and the same src and dst width/height. Could we move the full support for a resolution variant transformation to a separate fix? > > BIGC.getConfig() - I don't see where you put the scale into the BIGC > when you create it. Shouldn't the constructor with scales be used at > line 73? It is updated in the latest webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 which has been sent to the review: http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html For some reasons the link to the latest webrev and comments are not mentioned in this email. The BIGC:73 line has been corrected to: 73 ret = new BufferedImageGraphicsConfig(bImg, null, scaleX, scaleY); > > SGE.getScaleFactor() - suggestion: perhaps ignore an optional final > suffix "x" in the regular scale case so that they can say "=3.0x" to > mean the same as "=3"? It should also be updated in the latest webrev. Thanks, Alexandr. > > Looks almost good to go from my perspective. What is the plan for > Swing testing and fixing those bugs? > > ...jim > > On 10/22/15 8:28 AM, Alexander Scherbatiy wrote: >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8073320/webrev.02/ >> >> >> On 10/21/2015 5:40 PM, Sergey Bylokhov wrote: >>> I have two small suggestions: >>> - Probably it will be better to move the new properties from >>> Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at least >>> "sun.java2d.uiScale" should be implemented on linux, and can be >>> implemented on osx later. >> I have moved the uiScale properties initialization to the >> SunGraphicsEnvironment and Win32GraphicsEnvironment classes. >>> - I am worried about a rounding in >>> awt_Win32GraphicsDevice.ScaleDownXY/ScaleUpXY when these methods are >>> applied to the x/y and width/height. >> >> Could I move this update to a separate fix? >> >> Thanks, >> Alexandr. >> >>> >>> On 21.10.15 16:34, Alexander Scherbatiy wrote: >>>> >>>> Could you review the updated fix: >>>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.01/ >>>> >>>> - xform is concatenated with transform in >>>> SG2D.getResolutionVariant() >>>> method >>>> - imagepipe.transformImage() is used for drawImage(Image, >>>> AffineTransform,...) case >>>> - scale factors are made final in BufImgSurfaceData >>>> - two arrays are used for configs caching in BIGC >>>> - scale factors intialized from properties are moved to the static >>>> block in Win32GD >>>> >>>> On 10/10/2015 3:14 AM, Jim Graham wrote: >>>>> Hi Alexandr, >>>>> >>>>> Just 2 potential issues I found: >>>>> >>>>> SG2D.java - getResolutionVariant() doesn't take a transform so it >>>>> can't take into account the scaling in the transform handed to >>>>> drawImage(img, xform). We can leave that as a follow-on bug fix (it >>>>> won't do bad things, but it may not pick the best resolution source >>>>> image). >>>>> >>>>> WGLOffscreenSD (in WGLSD.java) - does peer.getBounds() cache the >>>>> bounds? >>>> >>>> No. peer.getBounds() directly calls targetComponent.getBounds() >>>> which returns a copy of original bounds. >>>> >>>> Thanks, >>>> Alexandr. >>>>> If so, then every time we call get bounds on the WGLWSD we will >>>>> permanently modify the peer's bounds. Would it be better to not make >>>>> the assumption and just make a protected copy here (perhaps with >>>>> scale >>>>> != 1?). >>>>> WGLWindowSD - same comment >>>>> D3DWindowSD - same comment >>>>> GDIWindowSD - same comment >>>>> >>>>> The rest of these are tweaks and optimizations. >>>>> >>>>> BISD.java - why do you have default initializers for the scale >>>>> fields? >>>>> (There are only 2 constructors to cover.) >>>>> >>>>> BIGC.java - [2][NUMTYPES] would involve a lot fewer objects than >>>>> [NUMTYPES][2]... >>>>> BIGC.java - Or... If we only have 2 variations of each type, why not >>>>> just have 2 static arrays instead of a double-indexed array? >>>>> int index = (scaleX && scaleY) ? 0 : 1; >>>>> becomes: >>>>> BIGC configarray = (scaleX && scaleY) ? standardArray : >>>>> scaledArray; >>>>> >>>>> SG2D.java - Another way of dealing with transform in scaleImage would >>>>> be to make a copy of the incoming transform and adjust it to match >>>>> the >>>>> request, as in: >>>>> // You can probably assert that dxywh == 0,0,imgW,imgH, or: >>>>> AffineTransform renderTX; >>>>> if (dxywh == 0,0,imgW,imgH) { >>>>> renderTX = xform; >>>>> } else { >>>>> // Should never happen in practice... >>>>> AffineTransform renderTX = new AffineTransform(xform); >>>>> renderTX.translate(dx1, dy1); >>>>> renderTX.scale((dx2 - dx1) / imgW, (dy2 - dy1) / imgH); >>>>> } >>>>> double-nested-try { >>>>> imagepipe.transformImage(..., renderTX); >>>>> } catch (InvalidPipe...) {...} >>>>> It would be more code, though, since you'd have to have 2 sets of >>>>> "double-nested-try-catch(InvalidPipe)" blocks. >>>>> >>>>> Win32GD.java - is there a need to have static initializers for the >>>>> scale fields? >>>>> >>>>> I'll leave the native code review to someone more familiar with that >>>>> code base... >>>>> >>>>> ...jim >>>>> >>>>> On 9/22/15 2:33 AM, Alexander Scherbatiy wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Could you review the fix: >>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073320 >>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 >>>>>> >>>>>> This is an initial part of the HiDPI Graphics support on Windows >>>>>> for >>>>>> the JEP 263: HiDPI Graphics on Windows and Linux >>>>>> http://openjdk.java.net/jeps/263 >>>>>> >>>>>> - scale factors are added to surface dates >>>>>> - window size, events coordinates and font are scaled on native >>>>>> side >>>>>> - backup buffered image is scaled in SunVolatileImage >>>>>> - AwtRobot MouseMove() and GetRGBPixels() methods are updated >>>>>> - GetDpiForMonitor function is used to query the specified >>>>>> monitor >>>>>> for the horizontal and vertical DPI values. >>>>>> If it is not available ID2D1Factory::GetDesktopDpi method is >>>>>> used >>>>>> instead. >>>>>> - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", >>>>>> "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are >>>>>> added for the testing purposes. >>>>>> >>>>>> Thanks, >>>>>> Alexandr. >>>>>> >>>> >>> >>> >> From Sergey.Bylokhov at oracle.com Wed Nov 11 16:48:01 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 11 Nov 2015 19:48:01 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <564321C0.9030106@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> Message-ID: <56437141.1020101@oracle.com> The latest version looks fine to me. A few notes. - SG2D.drawHiDPIImage does not take into account that MultiResolutionImage can contain VolatileImages. - Probably it will be better to move all code related to up/down scale from SG2D to the DrawImagePipe, which sometimes uses scaled coordinates and sometimes not. On 11.11.15 14:08, Alexander Scherbatiy wrote: > On 11/10/2015 10:41 PM, Jim Graham wrote: >> In drawHiDPIImage, in the VolatileImage case you ignore the transform, >> but I suppose that is OK because you pass it through to the >> scaleImage() case. However if it came in with a transform then the >> asserts at the top of scaleImage may fail? Maybe it would be better >> to actually handle the "non-0,0,iw,ih" case rather than assert that it >> doesn't exist? > The only case where xform is not null is the drawImage(img, xform, > observer) method which always use zero x, y and the same src and dst > width/height. > Could we move the full support for a resolution variant > transformation to a separate fix? > >> >> BIGC.getConfig() - I don't see where you put the scale into the BIGC >> when you create it. Shouldn't the constructor with scales be used at >> line 73? > > It is updated in the latest webrev: > http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 > which has been sent to the review: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html > > For some reasons the link to the latest webrev and comments are not > mentioned in this email. > > The BIGC:73 line has been corrected to: > 73 ret = new BufferedImageGraphicsConfig(bImg, null, > scaleX, scaleY); > >> >> SGE.getScaleFactor() - suggestion: perhaps ignore an optional final >> suffix "x" in the regular scale case so that they can say "=3.0x" to >> mean the same as "=3"? > > It should also be updated in the latest webrev. > > Thanks, > Alexandr. > >> >> Looks almost good to go from my perspective. What is the plan for >> Swing testing and fixing those bugs? >> >> ...jim >> >> On 10/22/15 8:28 AM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.02/ >>> >>> >>> On 10/21/2015 5:40 PM, Sergey Bylokhov wrote: >>>> I have two small suggestions: >>>> - Probably it will be better to move the new properties from >>>> Win32GraphicsDevice.java to SunGraphicsEnvironment.java, at least >>>> "sun.java2d.uiScale" should be implemented on linux, and can be >>>> implemented on osx later. >>> I have moved the uiScale properties initialization to the >>> SunGraphicsEnvironment and Win32GraphicsEnvironment classes. >>>> - I am worried about a rounding in >>>> awt_Win32GraphicsDevice.ScaleDownXY/ScaleUpXY when these methods are >>>> applied to the x/y and width/height. >>> >>> Could I move this update to a separate fix? >>> >>> Thanks, >>> Alexandr. >>> >>>> >>>> On 21.10.15 16:34, Alexander Scherbatiy wrote: >>>>> >>>>> Could you review the updated fix: >>>>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.01/ >>>>> >>>>> - xform is concatenated with transform in >>>>> SG2D.getResolutionVariant() >>>>> method >>>>> - imagepipe.transformImage() is used for drawImage(Image, >>>>> AffineTransform,...) case >>>>> - scale factors are made final in BufImgSurfaceData >>>>> - two arrays are used for configs caching in BIGC >>>>> - scale factors intialized from properties are moved to the static >>>>> block in Win32GD >>>>> >>>>> On 10/10/2015 3:14 AM, Jim Graham wrote: >>>>>> Hi Alexandr, >>>>>> >>>>>> Just 2 potential issues I found: >>>>>> >>>>>> SG2D.java - getResolutionVariant() doesn't take a transform so it >>>>>> can't take into account the scaling in the transform handed to >>>>>> drawImage(img, xform). We can leave that as a follow-on bug fix (it >>>>>> won't do bad things, but it may not pick the best resolution source >>>>>> image). >>>>>> >>>>>> WGLOffscreenSD (in WGLSD.java) - does peer.getBounds() cache the >>>>>> bounds? >>>>> >>>>> No. peer.getBounds() directly calls targetComponent.getBounds() >>>>> which returns a copy of original bounds. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>>> If so, then every time we call get bounds on the WGLWSD we will >>>>>> permanently modify the peer's bounds. Would it be better to not make >>>>>> the assumption and just make a protected copy here (perhaps with >>>>>> scale >>>>>> != 1?). >>>>>> WGLWindowSD - same comment >>>>>> D3DWindowSD - same comment >>>>>> GDIWindowSD - same comment >>>>>> >>>>>> The rest of these are tweaks and optimizations. >>>>>> >>>>>> BISD.java - why do you have default initializers for the scale >>>>>> fields? >>>>>> (There are only 2 constructors to cover.) >>>>>> >>>>>> BIGC.java - [2][NUMTYPES] would involve a lot fewer objects than >>>>>> [NUMTYPES][2]... >>>>>> BIGC.java - Or... If we only have 2 variations of each type, why not >>>>>> just have 2 static arrays instead of a double-indexed array? >>>>>> int index = (scaleX && scaleY) ? 0 : 1; >>>>>> becomes: >>>>>> BIGC configarray = (scaleX && scaleY) ? standardArray : >>>>>> scaledArray; >>>>>> >>>>>> SG2D.java - Another way of dealing with transform in scaleImage would >>>>>> be to make a copy of the incoming transform and adjust it to match >>>>>> the >>>>>> request, as in: >>>>>> // You can probably assert that dxywh == 0,0,imgW,imgH, or: >>>>>> AffineTransform renderTX; >>>>>> if (dxywh == 0,0,imgW,imgH) { >>>>>> renderTX = xform; >>>>>> } else { >>>>>> // Should never happen in practice... >>>>>> AffineTransform renderTX = new AffineTransform(xform); >>>>>> renderTX.translate(dx1, dy1); >>>>>> renderTX.scale((dx2 - dx1) / imgW, (dy2 - dy1) / imgH); >>>>>> } >>>>>> double-nested-try { >>>>>> imagepipe.transformImage(..., renderTX); >>>>>> } catch (InvalidPipe...) {...} >>>>>> It would be more code, though, since you'd have to have 2 sets of >>>>>> "double-nested-try-catch(InvalidPipe)" blocks. >>>>>> >>>>>> Win32GD.java - is there a need to have static initializers for the >>>>>> scale fields? >>>>>> >>>>>> I'll leave the native code review to someone more familiar with that >>>>>> code base... >>>>>> >>>>>> ...jim >>>>>> >>>>>> On 9/22/15 2:33 AM, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Could you review the fix: >>>>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8073320 >>>>>>> webrev: http://cr.openjdk.java.net/~alexsch/8073320/webrev.00 >>>>>>> >>>>>>> This is an initial part of the HiDPI Graphics support on Windows >>>>>>> for >>>>>>> the JEP 263: HiDPI Graphics on Windows and Linux >>>>>>> http://openjdk.java.net/jeps/263 >>>>>>> >>>>>>> - scale factors are added to surface dates >>>>>>> - window size, events coordinates and font are scaled on native >>>>>>> side >>>>>>> - backup buffered image is scaled in SunVolatileImage >>>>>>> - AwtRobot MouseMove() and GetRGBPixels() methods are updated >>>>>>> - GetDpiForMonitor function is used to query the specified >>>>>>> monitor >>>>>>> for the horizontal and vertical DPI values. >>>>>>> If it is not available ID2D1Factory::GetDesktopDpi method is >>>>>>> used >>>>>>> instead. >>>>>>> - "sun.java2d.uiScale.enabled", "sun.java2d.win.uiScale", >>>>>>> "sun.java2d.win.uiScaleX", and "sun.java2d.win.uiScaleY" options are >>>>>>> added for the testing purposes. >>>>>>> >>>>>>> Thanks, >>>>>>> Alexandr. >>>>>>> >>>>> >>>> >>>> >>> > -- Best regards, Sergey. From james.graham at oracle.com Wed Nov 11 21:31:24 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 11 Nov 2015 13:31:24 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <564321C0.9030106@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> Message-ID: <5643B3AC.8090608@oracle.com> On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: > For some reasons the link to the latest webrev and comments are not > mentioned in this email. I found it. I view this mailing list in threaded form and that email on 11/5 did not associate itself with the existing email thread... ...jim From Sergey.Bylokhov at oracle.com Wed Nov 11 23:09:30 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 02:09:30 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR: JDK-8132890: Text overlapping on dot matrix printers. In-Reply-To: <56431258.7090304@oracle.com> References: <563779D2.3000502@oracle.com> <56431258.7090304@oracle.com> Message-ID: <5643CAAA.3000902@oracle.com> Looks fine. On 11.11.15 13:03, mikhail cherkasov wrote: > Hi all, > > It's just kindly reminder about this review request. > > Thanks, > Mikhail. > > On 11/2/2015 17:57, mikhail cherkasov wrote: >> Hi All, >> >> Please review a backport of: >> https://bugs.openjdk.java.net/browse/JDK-8132890 >> to JDK8. >> >> The fix is the same, but the test was moved from closed part to open, >> so it's required to be >> reviewed. >> >> Webrev: >> http://cr.openjdk.java.net/~mcherkas/8132890/webrev.00/ >> >> jdk9 changeset: >> http://hg.openjdk.java.net/jdk9/client/jdk/rev/edec0fe63ceb >> >> Thanks, >> Mikhail. > -- Best regards, Sergey. From james.graham at oracle.com Wed Nov 11 23:33:31 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 11 Nov 2015 15:33:31 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <564321C0.9030106@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> Message-ID: <5643D04B.7030504@oracle.com> Hi Alexandr, On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: > On 11/10/2015 10:41 PM, Jim Graham wrote: >> In drawHiDPIImage, in the VolatileImage case you ignore the transform, >> but I suppose that is OK because you pass it through to the >> scaleImage() case. However if it came in with a transform then the >> asserts at the top of scaleImage may fail? Maybe it would be better >> to actually handle the "non-0,0,iw,ih" case rather than assert that it >> doesn't exist? > The only case where xform is not null is the drawImage(img, xform, > observer) method which always use zero x, y and the same src and dst > width/height. > Could we move the full support for a resolution variant > transformation to a separate fix? Ah, sorry, I was reading the old webrev.02 and also mixing up s[xy][12] (which are scaled) with d[xy][12] (which are the ones being compared). You are correct there. The new version in webrev.03 is a little clunky with having to modify the current transform, but it looks correct. >> BIGC.getConfig() - I don't see where you put the scale into the BIGC >> when you create it. Shouldn't the constructor with scales be used at >> line 73? > > It is updated in the latest webrev: > http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 > which has been sent to the review: > http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html Found the webrev.03 and it is already fixed as you say. >> SGE.getScaleFactor() - suggestion: perhaps ignore an optional final >> suffix "x" in the regular scale case so that they can say "=3.0x" to >> mean the same as "=3"? > > It should also be updated in the latest webrev. Found it. Looks good... >> Looks almost good to go from my perspective. What is the plan for >> Swing testing and fixing those bugs? The latest fix looks good to go. I was hoping to build it and test some swing apps, but I don't have a decent build environment ready to go yet. We need to be proactive about understanding how this affects Swing so that we can inform our developers about any changes they may need to make to look good under HiDPI and/or modify the approach to handle it ourselves... ...jim From mikhail.cherkasov at oracle.com Thu Nov 12 11:37:13 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Thu, 12 Nov 2015 14:37:13 +0300 Subject: [OpenJDK 2D-Dev] [8u-dev] RFR: JDK-8132890: Text overlapping on dot matrix printers. In-Reply-To: <5643CAAA.3000902@oracle.com> References: <563779D2.3000502@oracle.com> <56431258.7090304@oracle.com> <5643CAAA.3000902@oracle.com> Message-ID: <564479E9.1000206@oracle.com> Thank you! On 11/12/2015 02:09, Sergey Bylokhov wrote: > Looks fine. > > On 11.11.15 13:03, mikhail cherkasov wrote: >> Hi all, >> >> It's just kindly reminder about this review request. >> >> Thanks, >> Mikhail. >> >> On 11/2/2015 17:57, mikhail cherkasov wrote: >>> Hi All, >>> >>> Please review a backport of: >>> https://bugs.openjdk.java.net/browse/JDK-8132890 >>> to JDK8. >>> >>> The fix is the same, but the test was moved from closed part to open, >>> so it's required to be >>> reviewed. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~mcherkas/8132890/webrev.00/ >>> >>> jdk9 changeset: >>> http://hg.openjdk.java.net/jdk9/client/jdk/rev/edec0fe63ceb >>> >>> Thanks, >>> Mikhail. >> > > From Sergey.Bylokhov at oracle.com Thu Nov 12 13:02:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 16:02:42 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8137571 Linux HiDPI Graphics support In-Reply-To: <5641EC0F.5060304@oracle.com> References: <561282D7.6030402@oracle.com> <561858F6.5040306@oracle.com> <5628ECB1.7030606@oracle.com> <56297A29.9030101@oracle.com> <5629BDA8.8080909@oracle.com> <563C7A31.6040100@oracle.com> <563D4C21.2000103@oracle.com> <5641EC0F.5060304@oracle.com> Message-ID: <56448DF2.9050600@oracle.com> This version looks fine. A few notes which we discussed offline: - It will be good to understand how SG2D.copyarea should work in case of transformed graphics. - The different types of embedding should be checked(plugin,swt,fx). - I suggest to run some benchmarks to figure out what performance penalty we will get. On 10.11.15 16:07, Alexander Scherbatiy wrote: > On 11/7/2015 3:56 AM, Jim Graham wrote: >> It looks like the only remaining issues are: >> >> - Should we scale the origin of the screens so that they remain adjacent? > > The Toolkit defines only methods that allows to get size of the the > primary screen and screen insets which are rescaled in the provided fix. > The XGraphicsConfiguration bounds are also rescaled. > >> >> Questions that remain and may end up getting handled under followon bugs: >> >> - We should really think through rounding issues better in scaleDown() >> - We need to see if there can be a more accurate way to handle >> applyShape(Region) at the device scale. >> - DPI_SCALE needs to be handled eventually, don't let it fall through >> the cracks >> - Other Linux DPI attributes should be handled, hopefully there is a >> bug filed for that >> >> Some of those could be simply left for feedback from developers, but >> what is our plan to get our developers to do a decent amount of >> testing with their applications to let us know if our choices were fine? >> >> More comments inline below: >> >> On 11/6/15 2:00 AM, Alexander Scherbatiy wrote: >>> >>> Could you review the updated fix: >>> http://cr.openjdk.java.net/~alexsch/8137571/webrev.03/ >>> >>> - pixbuf is freed in the awt_Robot.c >>> - screenWidth/Height is rescaled in the XToolkit.initScreenSize() >>> method >> >> Is there also a position that needs to be adjusted? Is the convention >> that all screens should be directly adjacent, or can they float with >> gaps between them? > > The toolkit does not provide method to get the primary screen position. > I thought about adjusting screens with different scaling but it > looks like it is an additional task which can be handled in a separated > bug. >> >>> See more comments inline: >>> >>>>> In XComponentPeer we shouldn't be scaling a region, we should have >>>>> created the region in a scaled coordinate system... >>> >>> Could you give more details on this? >>> For example, we create a frame which is twice bigger than the >>> original one for the scale 2. >>> For this case it needs to scale the shape twice. The lox, loy, >>> hix, hiy values are calculated correctly. >>> The native function XShapeCombineRectangles is used to draw the >>> final shape for the given window. >> >> I suppose it may be architecturally difficult to do at this point, but >> ideally a Region should be a create-only structure that is produced at >> the desired device coordinate system and scaling. It might be >> necessary to perform integer translates on it as windows are moved >> around the screen from one integer location to another, but it should >> never be scaled. The fact that there is a method that can scale a >> region is basically an admission that we have not always done the >> right thing with respect to creating regions at device resolution. >> >> It looks like this may be the path of least resistance currently, but >> if we can improve the architecture to allow the Region to maintain >> full device resolution and not require any scaling that would be far >> better. > > I see now. >> >>>>> In XDragSourceContextPeer, should the scaledown try to do rounding? >>>>> Also, XMouseInfoPeer, lines 71,72? >>>>> Also, XToolkit, lines 725,726,855-858? >>>>> Also, XlibUtil, lines 129-131,159? >>>>> Also, X11GraphicsConfig, line 272? >>> I changed this to use scaleDown(x, scale) method from the >>> XlibUtil. >>> However, I am not sure about rounding. Only integer scale values >>> can be used. In this case x / 2 (3, 4, ...) returns a rounding to the >>> smallest value >>> which is what we probably need. >> >> The fact that only integer scaling values can be used only makes >> scaling up easier. It still begs the question of what value to report >> when we end up with X.5 or X.75 - should that be X or X+1? >> >> Why is truncation/rounding down what we need? Where is the analysis >> of how application behavior will be affected by rounding down vs. >> rounding up or rounding evenly? >> >> Note that in FX we have a number of different coordinate snapping >> functions that perform different rounding operations. Some are for >> sizes of things, some are for locations, and some are for calculating >> distributed distances during layout. > > It could be better to move the question about location, sizes and > distances scaling to a separate bug. The same question I also have for > the Windows HiDPI Graphics support. > > Thanks, > Alexandr. > >> >>>>> awt_GraphicsEnv.c - what about GDK_DPI_SCALE? It seems like it >>>>> might be >>>>> used to compensate for fonts on HiDPI screens that are already scaled >>>>> for the DPI, but if you honor GDK_SCALE then you will doubly-scale the >>>>> fonts. I'm not entirely sure I understand that, though, but it bares >>>>> further investigation... >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8058742 >>>> >>>> may be related to this GDK_DPI_SCALE issue... >>> I think yes. The GDK_DPI_SCALE can be used in the JDK-8058742 fix >>> to rescale GTK L&F UI sizes so they look in the same way as other L&Fs. >>> And the GDK_SCALE is used in the current fix to scale all UI. >>> It looks like there is no need to use the GDK_DPI_SCALE in the >>> current fix and I would prefer to not mix the current fix with the >>> JDK-8058742. >> >> OK, as long as we are aware of it and tracking it. It sounds like >> GDK_SCALE and GDK_DPI_SCALE come as a pair so I would have thought >> that they'd be implemented as part of the same fix, but as long as we >> get to it sooner rather than later, that's fine. >> >>>>> Also, is GDK_SCALE the only platform scale factor that Linux/X11 >>>>> might use? >>> >>> I used only GDK_SCALE in this fix. If there is another scale >>> factors it would be better to add them in another fix. >> >> True. I included this link in my HiDPI talk which appears to be a >> fairly comprehensive list: >> >> https://wiki.archlinux.org/index.php/HiDPI >> >> ...jim > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Nov 12 13:24:34 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 16:24:34 +0300 Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <5640957C.10702@oracle.com> References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com> Message-ID: <56449312.2000005@oracle.com> Hi, Jiri. This is a valid point, did you file a new CR for this issue? On 09.11.15 15:45, Alexander Scherbatiy wrote: > On 11/7/2015 11:38 AM, Jiri Vanek wrote: >> Hello! >> >> Looking to imageIO.java (if this is bad thread, please redirect me!) > > 2d-dev alias should be also the right place to ask image related > questions in AWT. > > Thanks, > Alexandr. > >> when reading images >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 >> >> and ending at: >> >> // Perform mark/reset as a defensive measure >> // even though plug-ins are supposed to take >> // care of it. >> boolean canDecode = false; >> if (stream != null) { >> stream.mark(); >> } >> canDecode = spi.canDecodeInput(input); >> if (stream != null) { >> stream.reset(); >> } >> return canDecode; >> >> I'm wondering, why stream.reset(); is not in finaly block: >> >> // Perform mark/reset as a defensive measure >> // even though plug-ins are supposed to take >> // care of it. >> boolean canDecode = false; >> if (stream != null) { >> stream.mark(); >> } >> try{ >> canDecode = spi.canDecodeInput(input); >> } finally { >> if (stream != null) { >> stream.reset(); >> } >> } >> return canDecode; >> >> >> Eg png and bmp decoders can are throwing IIOException when header is >> corrutped. That pretty definitely sure killer of stream mark stacks. >> You yourselves write : //Perform mark/reset as a defensive measure >> even though plug-ins are supposed to take care of it. >> So if densive, then try/finaly please. >> >> I did not check if this changed in 9 but if not....Please. This is >> makig work on custom image plugins, for image formats which just wraps >> another bmp/png and are expecting corrupted headers preatty hards. >> >> >> J. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Thu Nov 12 13:45:42 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Nov 2015 16:45:42 +0300 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java Message-ID: <56449806.5090703@oracle.com> Hello. Can somebody take a look to the small enhancement for DrawImage.java. I will file a new CR if the proposed change will be approved: http://cr.openjdk.java.net/~serb/perf/DrawImageItself.01/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html The goal is to minimize the calls to Blit.Blit/BlitBG() if we know that it will be noop. The reasons to the fix: - Not all blits are fast when the source and destination are the same. For example ByteBinary variants are quite slow. - In case of d3d and ogl such blit change the whole state of the render context and can slowdown the rendering to another destination. Notes: - In the common situation one additional statement "srcData == dstData" will be executed. - The comment about the 4783274 was removed, because I am not sure we really should copy this check from this particular method to all java blits? - Probably some other checks can be added as well? What about clipRegion.intersectsQuickCheckXYXY(dx,dy,dx+w,dy+h)? -- Best regards, Sergey. From philip.race at oracle.com Thu Nov 12 18:35:18 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Nov 2015 10:35:18 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. In-Reply-To: <56387767.7060101@oracle.com> References: <56387767.7060101@oracle.com> Message-ID: <5644DBE6.10303@oracle.com> Shouldn't this use reference equality ? Also the test does a number of wild card imports instead of the specific classes it needs. And I am not sure why it is importing java.awt.* anyway .. And I find qualifying "java.lang.String" to be unnecessary. -phil. On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 > webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ > > The issue was if we "cancel" Printer Job setup dialog which has been > created with DialogSelectionType.NATIVE > it should return "null" as per spec > https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- > /[If the user cancels the dialog, the attributes will not reflect any > changes made by the user, and the return value will be null.] > > /We were returning PageFormat instead. Fixed to return null in such case. > > Regards > Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Nov 12 18:40:34 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Nov 2015 10:40:34 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <48666932-8fbd-4588-9175-07acdd24d78b@default> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> Message-ID: <5644DD22.2080205@oracle.com> Please add a *public* evaluation to the bug report. I will look at it more then .. -phil. On 11/6/15, 2:20 AM, Jayathirth D V wrote: > > Hi Prasanta, > > As discussed, only in case of write_IDAT there is finally block which > calls ios.finish() which internally calls seek() with improper > startPos. In other cases we are not trying to access improper startPos > because there is no call to ios.finish(). We can verify this behavior > by changing logic where we throw IOException in test case. > > And I have modified test to not catch IOBE as per your suggestion. > Please find updated Webrev link: > > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Friday, November 06, 2015 2:45 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > *Cc:* Philip Race > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Hi Jay, > > looks ok but > I guess you need to do the same for finish() method too in similar way > you did for finishChunk() as finish() is called from write_IHDR, > write_CHRM etc and it calls flushBefore(). > Also, I guess you should not consume IOB Exception and let it be > thrown to user instead of RuntimeException after catching IOBE. > > Regards > Prasanta > > On 11/5/2015 5:25 PM, Jayathirth D V wrote: > > Hello All, > > Please review following fix in jdk9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 > > Webrev : > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ > > > Bug : IndexOutOfBoundsException when drawing PNGs > > Root cause : When user intentionally throws IO Exception while > write is happening. > We call ios.finish() in finally block of > write_IDAT() which internally goes to finishChunk(). But the > startPos of the chunk is still pointing to present IDAT chunk but > flushedPos(streamPos) is pointing to end of IDAT chunk. > So in finishChunk(), startPos will be > less than flushedPos. This is causing IndexOutOfBoundException in > stream.seek() and cache is not closed. > > Solution : If IOException is thrown by user, catch the exception > while write is happening and update startPos to streamPos. So that > when seek() happens in finishChunk() we don't see > IndexOutOfBoundsException and cache is closed properly. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Thu Nov 12 18:53:57 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Nov 2015 10:53:57 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8039412, , Stack overflow on Linux using DialogTypeSelection.NATIVE In-Reply-To: <563C885A.7080009@oracle.com> References: <563C885A.7080009@oracle.com> Message-ID: <5644E045.20409@oracle.com> I am 99% sure this breaks the API on Windows on Mac. Did you test what it does there ? Test has wild card imports again .. Also please add evaluation and explanation of the proposed fix into a public comment on the bug report before submitting for review. -phil. On 11/6/15, 3:00 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a fix for jdk9. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8039412 > webrev: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.00/ > > Issue was seen in linux whereby if we call PrinterJob.pageDialog() > after PrinterJob.printDialog() it results in StackOverflowError if > DialogSelectionType is NATIVE. > > This was because pageDialog(attributes) was calling > pageDialog(pageformat) if it is DialogTypeSelection.NATIVE which again > calls pageDialog(attributes) > via this code > http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l767 > > and > http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l743 > > > I added a fix whereby in pageDialog(attributes)we check if it is > DialogTypeSelection.NATIVE and remove this attribute temporarily > before calling pageDialog(pageformat) > and restore the DialogTypeSelection.NATIVE after the call. > It is similar to solution done in > http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l443 > > > Regards > Prasanta From james.graham at oracle.com Thu Nov 12 20:46:02 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 12 Nov 2015 12:46:02 -0800 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <56449806.5090703@oracle.com> References: <56449806.5090703@oracle.com> Message-ID: <5644FA8A.1050101@oracle.com> Hi Sergey, I think the added logic is fine, but I would hesitate removing all of those lines with comments simply because: - In terms of code generated it is no more efficient to do the tests up above or down below. - Your question below does not indicate enough investigation to remove that big long reminder, even if it is true that other pipelines need to have similar tests. Keep in mind that this is a reminder of why not to remove those checks even if they look like they don't really help anything and the amount of work it would take to eliminate them should we want to do that in the future... ...jim On 11/12/2015 5:45 AM, Sergey Bylokhov wrote: > Hello. > Can somebody take a look to the small enhancement for DrawImage.java. > > I will file a new CR if the proposed change will be approved: > http://cr.openjdk.java.net/~serb/perf/DrawImageItself.01/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html > > > The goal is to minimize the calls to Blit.Blit/BlitBG() if we know that > it will be noop. > The reasons to the fix: > - Not all blits are fast when the source and destination are the same. > For example ByteBinary variants are quite slow. > - In case of d3d and ogl such blit change the whole state of the > render context and can slowdown the rendering to another destination. > > Notes: > - In the common situation one additional statement "srcData == > dstData" will be executed. > - The comment about the 4783274 was removed, because I am not sure we > really should copy this check from this particular method to all java > blits? > - Probably some other checks can be added as well? What about > clipRegion.intersectsQuickCheckXYXY(dx,dy,dx+w,dy+h)? > > From Sergey.Bylokhov at oracle.com Thu Nov 12 21:54:09 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Nov 2015 00:54:09 +0300 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <5644FA8A.1050101@oracle.com> References: <56449806.5090703@oracle.com> <5644FA8A.1050101@oracle.com> Message-ID: <56450A81.3070001@oracle.com> On 12.11.15 23:46, Jim Graham wrote: > Hi Sergey, > > I think the added logic is fine, but I would hesitate removing all of > those lines with comments simply because: > > - In terms of code generated it is no more efficient to do the tests up > above or down below. > > - Your question below does not indicate enough investigation to remove > that big long reminder, even if it is true that other pipelines need to > have similar tests. Keep in mind that this is a reminder of why not to > remove those checks even if they look like they don't really help > anything and the amount of work it would take to eliminate them should > we want to do that in the future... Actually my intention was to create the small and fast list of checks, which allow us totally to skip all Blits machinery. - We will save a few time on blit lookup. - Most of the OGL/d3d blits have such checks, but they are implemented in the native code which will be executed after we posted the necessary operations to the OGLRenderQueue. For example take a look to the OGLBlitLoops.IsoBlit(). This method uses rq.lock(), then calls validateContext() which can be extremely slow if the clip is not rectangle(see BufferedContext.setClip()), and then this method calls rq.flushNow()!!! Even if such operations in the OGLBlitLoops.IsoBlit() for particular destination will be fast, they will change the current OGL context. This can slowdown rendering to another destination, because another blit should restore the context. The possible solution for such issues is to add these checks to the java blits in OGLBlitLoops and to related blits in d3d. But I assume that DrawImage.blitSurfaceData is a better place. This is why I also requested some other fast checks which can speedup us, like clipRegion.intersectsQuickCheckXYXY(dx,dy,dx+w,dy+h) I can add a comment that this code is for performance, what do you think? > > ...jim > > On 11/12/2015 5:45 AM, Sergey Bylokhov wrote: >> Hello. >> Can somebody take a look to the small enhancement for DrawImage.java. >> >> I will file a new CR if the proposed change will be approved: >> http://cr.openjdk.java.net/~serb/perf/DrawImageItself.01/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html >> >> >> >> The goal is to minimize the calls to Blit.Blit/BlitBG() if we know that >> it will be noop. >> The reasons to the fix: >> - Not all blits are fast when the source and destination are the same. >> For example ByteBinary variants are quite slow. >> - In case of d3d and ogl such blit change the whole state of the >> render context and can slowdown the rendering to another destination. >> >> Notes: >> - In the common situation one additional statement "srcData == >> dstData" will be executed. >> - The comment about the 4783274 was removed, because I am not sure we >> really should copy this check from this particular method to all java >> blits? >> - Probably some other checks can be added as well? What about >> clipRegion.intersectsQuickCheckXYXY(dx,dy,dx+w,dy+h)? >> >> -- Best regards, Sergey. From james.graham at oracle.com Thu Nov 12 22:50:37 2015 From: james.graham at oracle.com (Jim Graham) Date: Thu, 12 Nov 2015 14:50:37 -0800 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <56450A81.3070001@oracle.com> References: <56449806.5090703@oracle.com> <5644FA8A.1050101@oracle.com> <56450A81.3070001@oracle.com> Message-ID: <564517BD.7000105@oracle.com> Hi Sergey, On 11/12/2015 1:54 PM, Sergey Bylokhov wrote: > On 12.11.15 23:46, Jim Graham wrote: >> Hi Sergey, >> >> I think the added logic is fine, but I would hesitate removing all of >> those lines with comments simply because: >> >> - In terms of code generated it is no more efficient to do the tests up >> above or down below. >> >> - Your question below does not indicate enough investigation to remove >> that big long reminder, even if it is true that other pipelines need to >> have similar tests. Keep in mind that this is a reminder of why not to >> remove those checks even if they look like they don't really help >> anything and the amount of work it would take to eliminate them should >> we want to do that in the future... > > Actually my intention was to create the small and fast list of checks, > which allow us totally to skip all Blits machinery. I agree with that. I'm just saying that it would be better to leave the w,h tests where they are with their big comment and not to touch that part of the code. The rest of the tests (testing for copying bits to the same location on the same SD) have to appear a few lines further down in the code, but that's fine. I don't think placing all possible tests that can contribute to short-cutting the operation in a single place with a single if statement is that much of a gain compared to leaving in that big comment. > I can add a comment that this code is for performance, what do you think? I'd like to see that, was there an updated diff? In either case, I don't think we should disturb the comment and test at the top, we should just add additional checks down below where you have them now... ...jim From jayathirth.d.v at oracle.com Fri Nov 13 04:11:58 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 12 Nov 2015 20:11:58 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <5644DD22.2080205@oracle.com> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> <5644DD22.2080205@oracle.com> Message-ID: <3ea69749-8b12-43ca-bb53-3db53eb8d26b@default> Hi Phil, I have added public evaluation in bug. Please review. Thanks, Jay From: Philip Race Sent: Friday, November 13, 2015 12:11 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Please add a *public* evaluation to the bug report. I will look at it more then .. -phil. On 11/6/15, 2:20 AM, Jayathirth D V wrote: Hi Prasanta, As discussed, only in case of write_IDAT there is finally block which calls ios.finish() which internally calls seek() with improper startPos. In other cases we are not trying to access improper startPos because there is no call to ios.finish(). We can verify this behavior by changing logic where we throw IOException in test case. And I have modified test to not catch IOBE as per your suggestion. Please find updated Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.01/"http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ Thanks, Jay From: prasanta sadhukhan Sent: Friday, November 06, 2015 2:45 PM To: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Hi Jay, looks ok but I guess you need to do the same for finish() method too in similar way you did for finishChunk() as finish() is called from write_IHDR, write_CHRM etc and it calls flushBefore(). Also, I guess you should not consume IOB Exception and let it be thrown to user instead of RuntimeException after catching IOBE. Regards Prasanta On 11/5/2015 5:25 PM, Jayathirth D V wrote: Hello All, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.00/"http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ Bug : IndexOutOfBoundsException when drawing PNGs Root cause : When user intentionally throws IO Exception while write is happening. We call ios.finish() in finally block of write_IDAT() which internally goes to finishChunk(). But the startPos of the chunk is still pointing to present IDAT chunk but flushedPos(streamPos) is pointing to end of IDAT chunk. So in finishChunk(), startPos will be less than flushedPos. This is causing IndexOutOfBoundException in stream.seek() and cache is not closed. Solution : If IOException is thrown by user, catch the exception while write is happening and update startPos to streamPos. So that when seek() happens in finishChunk() we don't see IndexOutOfBoundsException and cache is closed properly. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Nov 13 05:48:55 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Nov 2015 21:48:55 -0800 Subject: [OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode Message-ID: <564579C7.9070604@oracle.com> Bug: https://bugs.openjdk.java.net/browse/JDK-7162125 Fix: http://cr.openjdk.java.net/~prr/7162125/ The problem is that complex text layout and accompanying typographic support is largely limping along on OS X and then only thanks to some canonical tables that the ICU library has. The bug is that the internal font "peer" that passes the font tables containing the necessary information for OpenType (and AAT) layout does not implement the necessary functions. So there is no way to get the information that the font itself contains, resulting in incorrect rendering. The fix needs to be to add to the osx "CFont" class the necessary code to pass that information. That is not so hard. But there is an additional complication that the OS X code uses "fallback" or "substitution" or "cascading" fonts and so a font like "Lucida Grande" might report that it supports code points from Indic scripts when it does not. It does this by reporting negative glyph codes for such cases and fixes it up in the final rendering step. The problem with that is that layout needs to use the font-specific tables and this subverts that. We need to know for sure which code points are supported and split into runs of text that the font supports. So we need to find the real fonts that the CFont uses. In core text this is obtainable as the cascading font list. We can get this and construct a CompositeFont and make its glyph mapper check that there are no *negative* glyph codes not just no zero ones. Now we can give layout proper runs and tables. The final bit is that rendering needs to also know that if it is passed a font that might implement FontSubstition that it needs to expect that layout returned glyph codes that are intended to be used with the Composite. A reliable regression test is tricky. I have looked for a simple code point sequence that an installed OS X font provides that I can "measure" to see that the ligature forms but have not found one. I have however tested using the font provided in https://bugs.openjdk.java.net/browse/JDK-8139741 but I cannot check that in. -phil. From prasanta.sadhukhan at oracle.com Fri Nov 13 05:52:13 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 13 Nov 2015 11:22:13 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. In-Reply-To: <5644DBE6.10303@oracle.com> References: <56387767.7060101@oracle.com> <5644DBE6.10303@oracle.com> Message-ID: <56457A8D.9010104@oracle.com> Hi Phil, On 11/13/2015 12:05 AM, Philip Race wrote: > Shouldn't this use reference equality ? It seems Object.java equals() method does == anyways and it seems it always better to call equals() than to explicitly check for == Is it not correct? If it is not, I will change it. > Also the test does a number of wild card imports instead of > the specific classes it needs. And I am not sure why it > is importing java.awt.* anyway .. > > And I find qualifying "java.lang.String" to be unnecessary. will update the test. Regards Prasanta > > -phil. > > On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ >> >> The issue was if we "cancel" Printer Job setup dialog which has been >> created with DialogSelectionType.NATIVE >> it should return "null" as per spec >> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- >> /[If the user cancels the dialog, the attributes will not reflect any >> changes made by the user, and the return value will be null.] >> >> /We were returning PageFormat instead. Fixed to return null in such >> case. >> >> Regards >> Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Fri Nov 13 06:05:47 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 12 Nov 2015 22:05:47 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. In-Reply-To: <56457A8D.9010104@oracle.com> References: <56387767.7060101@oracle.com> <5644DBE6.10303@oracle.com> <56457A8D.9010104@oracle.com> Message-ID: <56457DBB.50803@oracle.com> On 11/12/15, 9:52 PM, prasanta sadhukhan wrote: > Hi Phil, > > On 11/13/2015 12:05 AM, Philip Race wrote: >> Shouldn't this use reference equality ? > It seems Object.java equals() method does == anyways and it seems it > always better to call equals() than to explicitly check for == > Is it not correct? If it is not, I will change it. You are relying on PageFormat not over-riding equals. It could do so and then the intent of your equals call would be broken in the case that updates to the dialog resulted in a new PageFormat but with the equal fieids. -phil. >> Also the test does a number of wild card imports instead of >> the specific classes it needs. And I am not sure why it >> is importing java.awt.* anyway .. >> >> And I find qualifying "java.lang.String" to be unnecessary. > will update the test. > > Regards > Prasanta >> >> -phil. >> >> On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ >>> >>> The issue was if we "cancel" Printer Job setup dialog which has been >>> created with DialogSelectionType.NATIVE >>> it should return "null" as per spec >>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- >>> /[If the user cancels the dialog, the attributes will not reflect >>> any changes made by the user, and the return value will be null.] >>> >>> /We were returning PageFormat instead. Fixed to return null in such >>> case. >>> >>> Regards >>> Prasanta > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Nov 13 06:23:42 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 13 Nov 2015 11:53:42 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. In-Reply-To: <56457DBB.50803@oracle.com> References: <56387767.7060101@oracle.com> <5644DBE6.10303@oracle.com> <56457A8D.9010104@oracle.com> <56457DBB.50803@oracle.com> Message-ID: <564581EE.3040803@oracle.com> Thanks Phil. I was indeed relying on non-presence of equals method in PageFormat. I have modified the webrev to use equality. Can you please review ? http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.01/ Regards Prasanta On 11/13/2015 11:35 AM, Philip Race wrote: > > > On 11/12/15, 9:52 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 11/13/2015 12:05 AM, Philip Race wrote: >>> Shouldn't this use reference equality ? >> It seems Object.java equals() method does == anyways and it seems it >> always better to call equals() than to explicitly check for == >> Is it not correct? If it is not, I will change it. > > You are relying on PageFormat not over-riding equals. > It could do so and then the intent of your equals call would be broken > in the case that updates to the dialog resulted in a new PageFormat > but with the equal fieids. > > -phil. > >>> Also the test does a number of wild card imports instead of >>> the specific classes it needs. And I am not sure why it >>> is importing java.awt.* anyway .. >>> >>> And I find qualifying "java.lang.String" to be unnecessary. >> will update the test. >> >> Regards >> Prasanta >>> >>> -phil. >>> >>> On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: >>>> Hi All, >>>> >>>> Please review a fix for jdk9. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 >>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ >>>> >>>> The issue was if we "cancel" Printer Job setup dialog which has >>>> been created with DialogSelectionType.NATIVE >>>> it should return "null" as per spec >>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- >>>> /[If the user cancels the dialog, the attributes will not reflect >>>> any changes made by the user, and the return value will be null.] >>>> >>>> /We were returning PageFormat instead. Fixed to return null in such >>>> case. >>>> >>>> Regards >>>> Prasanta >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Fri Nov 13 08:24:33 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 13 Nov 2015 13:54:33 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8039412, , Stack overflow on Linux using DialogTypeSelection.NATIVE In-Reply-To: <5644E045.20409@oracle.com> References: <563C885A.7080009@oracle.com> <5644E045.20409@oracle.com> Message-ID: <56459E41.7070004@oracle.com> Hi Phil, On 11/13/2015 12:23 AM, Philip Race wrote: > I am 99% sure this breaks the API on Windows on Mac. > Did you test what it does there ? > It works on Windows as PrinterJob.pageDialog(attributes) calls pageDialog(PageFormat page) in WPrinterJob.java which overrides pageDialog(PageFormat) of RasterPrinterJob It also works on Mac as PrinterJob.pageDialog(attributes) calls pageDialog(PageFormat page) in CPrinterJob.java which overrides pageDialog(PageFormat) of RasterPrinterJob I actually mistakenly mentioned down below that the check was added in pageDialog(attributes) whereas actually the temporary removal and addition was added in pageDialog(PageFormat) so it only affects linux printing dialog. > Test has wild card imports again .. Corrected wild card imports. Updated webrev is here: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.01/ > > Also please add evaluation and explanation of the proposed fix into a > public comment on the bug report before submitting for review. > Added public comment. Regards Prasanta > -phil. > > On 11/6/15, 3:00 AM, prasanta sadhukhan wrote: >> Hi All, >> >> Please review a fix for jdk9. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8039412 >> webrev: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.00/ >> >> Issue was seen in linux whereby if we call PrinterJob.pageDialog() >> after PrinterJob.printDialog() it results in StackOverflowError if >> DialogSelectionType is NATIVE. >> >> This was because pageDialog(attributes) was calling >> pageDialog(pageformat) if it is DialogTypeSelection.NATIVE which >> again calls pageDialog(attributes) >> via this code >> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l767 >> >> and >> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l743 >> >> >> I added a fix whereby in pageDialog(attributes)we check if it is >> DialogTypeSelection.NATIVE and remove this attribute temporarily >> before calling pageDialog(pageformat) >> and restore the DialogTypeSelection.NATIVE after the call. >> It is similar to solution done in >> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l443 >> >> >> Regards >> Prasanta From alexandr.scherbatiy at oracle.com Fri Nov 13 16:46:21 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 13 Nov 2015 19:46:21 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <5643D04B.7030504@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> <5643D04B.7030504@oracle.com> Message-ID: <564613DD.8070005@oracle.com> Hello, I have filled additional issues which has been discussed on the review: JDK-8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display JDK-8142966 Wrong cursor position in text components on HiDPI display JDK-8142961 Position, size and distance scaling for HiDPI graphics support JDK-8142963 Better transformImage support for HiDPI images JDK-8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics JDK-8142965 Consider the case where MRI can contains VolatileImage Thanks, Alexandr. On 11/12/2015 2:33 AM, Jim Graham wrote: > Hi Alexandr, > > On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: >> On 11/10/2015 10:41 PM, Jim Graham wrote: >>> In drawHiDPIImage, in the VolatileImage case you ignore the transform, >>> but I suppose that is OK because you pass it through to the >>> scaleImage() case. However if it came in with a transform then the >>> asserts at the top of scaleImage may fail? Maybe it would be better >>> to actually handle the "non-0,0,iw,ih" case rather than assert that it >>> doesn't exist? >> The only case where xform is not null is the drawImage(img, xform, >> observer) method which always use zero x, y and the same src and dst >> width/height. >> Could we move the full support for a resolution variant >> transformation to a separate fix? > > Ah, sorry, I was reading the old webrev.02 and also mixing up > s[xy][12] (which are scaled) with d[xy][12] (which are the ones being > compared). You are correct there. > > The new version in webrev.03 is a little clunky with having to modify > the current transform, but it looks correct. > >>> BIGC.getConfig() - I don't see where you put the scale into the BIGC >>> when you create it. Shouldn't the constructor with scales be used at >>> line 73? >> >> It is updated in the latest webrev: >> http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 >> which has been sent to the review: >> http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html > > Found the webrev.03 and it is already fixed as you say. > >>> SGE.getScaleFactor() - suggestion: perhaps ignore an optional final >>> suffix "x" in the regular scale case so that they can say "=3.0x" to >>> mean the same as "=3"? >> >> It should also be updated in the latest webrev. > > Found it. Looks good... > >>> Looks almost good to go from my perspective. What is the plan for >>> Swing testing and fixing those bugs? > > The latest fix looks good to go. I was hoping to build it and test > some swing apps, but I don't have a decent build environment ready to > go yet. We need to be proactive about understanding how this affects > Swing so that we can inform our developers about any changes they may > need to make to look good under HiDPI and/or modify the approach to > handle it ourselves... > > ...jim From Sergey.Bylokhov at oracle.com Fri Nov 13 20:12:07 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 13 Nov 2015 23:12:07 +0300 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <564517BD.7000105@oracle.com> References: <56449806.5090703@oracle.com> <5644FA8A.1050101@oracle.com> <56450A81.3070001@oracle.com> <564517BD.7000105@oracle.com> Message-ID: <56464417.2000300@oracle.com> On 13.11.15 1:50, Jim Graham wrote: >> I can add a comment that this code is for performance, what do you think? > > I'd like to see that, was there an updated diff? In either case, I > don't think we should disturb the comment and test at the top, we should > just add additional checks down below where you have them now... The code for w/h was reverted. Probably I will try change it later in another fix, after verification of our java blits and the fix for JDK-4783274. http://cr.openjdk.java.net/~serb/perf/DrawImageItself.02/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html -- Best regards, Sergey. From james.graham at oracle.com Fri Nov 13 20:43:48 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 13 Nov 2015 12:43:48 -0800 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <56464417.2000300@oracle.com> References: <56449806.5090703@oracle.com> <5644FA8A.1050101@oracle.com> <56450A81.3070001@oracle.com> <564517BD.7000105@oracle.com> <56464417.2000300@oracle.com> Message-ID: <56464B84.5010500@oracle.com> Looks good! ...jim On 11/13/2015 12:12 PM, Sergey Bylokhov wrote: > On 13.11.15 1:50, Jim Graham wrote: >>> I can add a comment that this code is for performance, what do you >>> think? >> >> I'd like to see that, was there an updated diff? In either case, I >> don't think we should disturb the comment and test at the top, we should >> just add additional checks down below where you have them now... > > The code for w/h was reverted. Probably I will try change it later in > another fix, after verification of our java blits and the fix for > JDK-4783274. > > http://cr.openjdk.java.net/~serb/perf/DrawImageItself.02/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html > > From philip.race at oracle.com Fri Nov 13 22:26:05 2015 From: philip.race at oracle.com (Philip Race) Date: Fri, 13 Nov 2015 14:26:05 -0800 Subject: [OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode In-Reply-To: <564579C7.9070604@oracle.com> References: <564579C7.9070604@oracle.com> Message-ID: <5646637D.40403@oracle.com> I have managed to create a regression test that I think I can trust on OS X Updated webrev :- http://cr.openjdk.java.net/~prr/7162125.1 -phil. On 11/12/15, 9:48 PM, Philip Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-7162125 > Fix: http://cr.openjdk.java.net/~prr/7162125/ > > The problem is that complex text layout and accompanying typographic > support > is largely limping along on OS X and then only thanks to some canonical > tables that the ICU library has. > > The bug is that the internal font "peer" that passes the font tables > containing the necessary information for OpenType (and AAT) layout > does not implement the necessary functions. So there is no way to > get the information that the font itself contains, resulting in incorrect > rendering. > > The fix needs to be to add to the osx "CFont" class the necessary > code to pass that information. That is not so hard. > > But there is an additional complication that the OS X code uses > "fallback" or "substitution" or "cascading" fonts and so a font > like "Lucida Grande" might report that it supports code points > from Indic scripts when it does not. It does this by reporting > negative glyph codes for such cases and fixes it up in the final > rendering step. The problem with that is that layout needs to > use the font-specific tables and this subverts that. We need > to know for sure which code points are supported and split > into runs of text that the font supports. So we need to find > the real fonts that the CFont uses. In core text this is obtainable > as the cascading font list. We can get this and construct a > CompositeFont and make its glyph mapper check that there > are no *negative* glyph codes not just no zero ones. > > Now we can give layout proper runs and tables. > The final bit is that rendering needs to also know that if it > is passed a font that might implement FontSubstition that > it needs to expect that layout returned glyph codes that > are intended to be used with the Composite. > > A reliable regression test is tricky. I have looked for a simple > code point sequence that an installed OS X font provides that I can > "measure" to see that the ligature forms but have not found one. > > I have however tested using the font provided in > https://bugs.openjdk.java.net/browse/JDK-8139741 > but I cannot check that in. > > -phil. > > > > > > From alexandr.scherbatiy at oracle.com Mon Nov 16 14:07:14 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Mon, 16 Nov 2015 17:07:14 +0300 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5633C7C8.2030804@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> Message-ID: <5649E312.2010606@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 - round is used instead of ceil - inverted scales are used Thanks, Alexandr. On 10/30/2015 10:40 PM, Jim Graham wrote: > In this case round may be better. ceil() is more for cases where you > needed "at least X amount of room", but I don't think a font size is > an "at least this much" kind of case. > > Also, I've been toying with the idea that use of ceil() and floor() in > any DPI-adjustment equations should really be "ceil(val - epsilon)" or > "floor(ceil + epsilon)" for some small value of epsilon chosen just > large enough to prevent various round-off errors from affecting the > outcome. One idea is for 1/256 as the value of epsilon since that > could equate to the smallest measurable difference in terms of alpha > or interpolation results (or 1/512 for "half the smallest quantum")... > > ...jim > > On 10/29/15 1:36 PM, Phil Race wrote: >> size->cx = (int)ceil(size->cx / scale); >> >> >> So if size->cx / scale works out to be 12.0001 you will round it up >> to 13? >> >> Can you check what pixel size windows gives you in such a case ? >> I'd be a little surprised if they did that rather than round. >> >> Is the SetFontProperty that does not accept a scale parameter still used >> somewhere ? >> >> -phil. >> >> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>> >>>>> - Sergey's point about multi-mon should be checked out. >>>> Windows 8.1 has option "Let me choose one scaling level for >>>> all my >>>> displays". >>>> If I unset it I am able to change the size of all items. However, >>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI displays. >>> >>> This version looks fine, but I am sure it can be double checked on >>> windows 10 at some moment as well. >>> >>> >> From steven.loomis at oracle.com Mon Nov 16 17:53:15 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Mon, 16 Nov 2015 09:53:15 -0800 Subject: [OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode In-Reply-To: <5646637D.40403@oracle.com> References: <564579C7.9070604@oracle.com> <5646637D.40403@oracle.com> Message-ID: <564A180B.7070903@oracle.com> This looks good to me. -s On 11/13/2015 2:26 PM, Philip Race wrote: > I have managed to create a regression test that I think I can trust on > OS X > Updated webrev :- http://cr.openjdk.java.net/~prr/7162125.1 > > -phil. > > On 11/12/15, 9:48 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-7162125 >> Fix: http://cr.openjdk.java.net/~prr/7162125/ >> >> The problem is that complex text layout and accompanying typographic >> support >> is largely limping along on OS X and then only thanks to some canonical >> tables that the ICU library has. >> >> The bug is that the internal font "peer" that passes the font tables >> containing the necessary information for OpenType (and AAT) layout >> does not implement the necessary functions. So there is no way to >> get the information that the font itself contains, resulting in >> incorrect >> rendering. >> >> The fix needs to be to add to the osx "CFont" class the necessary >> code to pass that information. That is not so hard. >> >> But there is an additional complication that the OS X code uses >> "fallback" or "substitution" or "cascading" fonts and so a font >> like "Lucida Grande" might report that it supports code points >> from Indic scripts when it does not. It does this by reporting >> negative glyph codes for such cases and fixes it up in the final >> rendering step. The problem with that is that layout needs to >> use the font-specific tables and this subverts that. We need >> to know for sure which code points are supported and split >> into runs of text that the font supports. So we need to find >> the real fonts that the CFont uses. In core text this is obtainable >> as the cascading font list. We can get this and construct a >> CompositeFont and make its glyph mapper check that there >> are no *negative* glyph codes not just no zero ones. >> >> Now we can give layout proper runs and tables. >> The final bit is that rendering needs to also know that if it >> is passed a font that might implement FontSubstition that >> it needs to expect that layout returned glyph codes that >> are intended to be used with the Composite. >> >> A reliable regression test is tricky. I have looked for a simple >> code point sequence that an installed OS X font provides that I can >> "measure" to see that the ligature forms but have not found one. >> >> I have however tested using the font provided in >> https://bugs.openjdk.java.net/browse/JDK-8139741 >> but I cannot check that in. >> >> -phil. >> >> >> >> >> >> From jennifer.godinez at oracle.com Mon Nov 16 18:00:23 2015 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Mon, 16 Nov 2015 10:00:23 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. Message-ID: Looks good. Approved. Jennifer ----- Original Message ----- From: prasanta.sadhukhan at oracle.com To: philip.race at oracle.com Cc: 2d-dev at openjdk.java.net, rajeev.chamyal at oracle.com Sent: Friday, November 13, 2015 3:36:15 AM GMT -08:00 US/Canada Pacific Subject: Re: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. Thanks Phil. I was indeed relying on non-presence of equals method in PageFormat. I have modified the webrev to use equality. Can you please review ? http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.01/ Regards Prasanta On 11/13/2015 11:35 AM, Philip Race wrote: On 11/12/15, 9:52 PM, prasanta sadhukhan wrote: Hi Phil, On 11/13/2015 12:05 AM, Philip Race wrote: Shouldn't this use reference equality ? It seems Object.java equals() method does == anyways and it seems it always better to call equals() than to explicitly check for == Is it not correct? If it is not, I will change it. You are relying on PageFormat not over-riding equals. It could do so and then the intent of your equals call would be broken in the case that updates to the dialog resulted in a new PageFormat but with the equal fieids. -phil. Also the test does a number of wild card imports instead of the specific classes it needs. And I am not sure why it is importing java.awt.* anyway .. And I find qualifying "java.lang.String" to be unnecessary. will update the test. Regards Prasanta -phil. On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: Hi All, Please review a fix for jdk9. Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ The issue was if we "cancel" Printer Job setup dialog which has been created with DialogSelectionType.NATIVE it should return "null" as per spec https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet - [If the user cancels the dialog, the attributes will not reflect any changes made by the user, and the return value will be null.] We were returning PageFormat instead. Fixed to return null in such case. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.loomis at oracle.com Mon Nov 16 18:00:55 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Mon, 16 Nov 2015 10:00:55 -0800 Subject: [OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode In-Reply-To: <5646637D.40403@oracle.com> References: <564579C7.9070604@oracle.com> <5646637D.40403@oracle.com> Message-ID: <564A19D7.4030809@oracle.com> This looks good to me. -s On 11/13/2015 2:26 PM, Philip Race wrote: > I have managed to create a regression test that I think I can trust on > OS X > Updated webrev :- http://cr.openjdk.java.net/~prr/7162125.1 > > -phil. > > On 11/12/15, 9:48 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-7162125 >> Fix: http://cr.openjdk.java.net/~prr/7162125/ >> >> The problem is that complex text layout and accompanying typographic >> support >> is largely limping along on OS X and then only thanks to some canonical >> tables that the ICU library has. >> >> The bug is that the internal font "peer" that passes the font tables >> containing the necessary information for OpenType (and AAT) layout >> does not implement the necessary functions. So there is no way to >> get the information that the font itself contains, resulting in >> incorrect >> rendering. >> >> The fix needs to be to add to the osx "CFont" class the necessary >> code to pass that information. That is not so hard. >> >> But there is an additional complication that the OS X code uses >> "fallback" or "substitution" or "cascading" fonts and so a font >> like "Lucida Grande" might report that it supports code points >> from Indic scripts when it does not. It does this by reporting >> negative glyph codes for such cases and fixes it up in the final >> rendering step. The problem with that is that layout needs to >> use the font-specific tables and this subverts that. We need >> to know for sure which code points are supported and split >> into runs of text that the font supports. So we need to find >> the real fonts that the CFont uses. In core text this is obtainable >> as the cascading font list. We can get this and construct a >> CompositeFont and make its glyph mapper check that there >> are no *negative* glyph codes not just no zero ones. >> >> Now we can give layout proper runs and tables. >> The final bit is that rendering needs to also know that if it >> is passed a font that might implement FontSubstition that >> it needs to expect that layout returned glyph codes that >> are intended to be used with the Composite. >> >> A reliable regression test is tricky. I have looked for a simple >> code point sequence that an installed OS X font provides that I can >> "measure" to see that the ligature forms but have not found one. >> >> I have however tested using the font provided in >> https://bugs.openjdk.java.net/browse/JDK-8139741 >> but I cannot check that in. >> >> -phil. >> >> >> >> >> >> From philip.race at oracle.com Mon Nov 16 18:08:32 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 10:08:32 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-8067059, , PrinterJob.pageDialog() with DialogSelectionType.NATIVE returns a PageFormat when cancelled. In-Reply-To: <564581EE.3040803@oracle.com> References: <56387767.7060101@oracle.com> <5644DBE6.10303@oracle.com> <56457A8D.9010104@oracle.com> <56457DBB.50803@oracle.com> <564581EE.3040803@oracle.com> Message-ID: <564A1BA0.1050607@oracle.com> Approved. -phil. On 11/12/2015 10:23 PM, prasanta sadhukhan wrote: > Thanks Phil. I was indeed relying on non-presence of equals method in > PageFormat. > > I have modified the webrev to use equality. Can you please review ? > http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.01/ > > Regards > Prasanta > On 11/13/2015 11:35 AM, Philip Race wrote: >> >> >> On 11/12/15, 9:52 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 11/13/2015 12:05 AM, Philip Race wrote: >>>> Shouldn't this use reference equality ? >>> It seems Object.java equals() method does == anyways and it seems it >>> always better to call equals() than to explicitly check for == >>> Is it not correct? If it is not, I will change it. >> >> You are relying on PageFormat not over-riding equals. >> It could do so and then the intent of your equals call would be broken >> in the case that updates to the dialog resulted in a new PageFormat >> but with the equal fieids. >> >> -phil. >> >>>> Also the test does a number of wild card imports instead of >>>> the specific classes it needs. And I am not sure why it >>>> is importing java.awt.* anyway .. >>>> >>>> And I find qualifying "java.lang.String" to be unnecessary. >>> will update the test. >>> >>> Regards >>> Prasanta >>>> >>>> -phil. >>>> >>>> On 11/3/15, 12:59 AM, prasanta sadhukhan wrote: >>>>> Hi All, >>>>> >>>>> Please review a fix for jdk9. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067059 >>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8067059/webrev.00/ >>>>> >>>>> The issue was if we "cancel" Printer Job setup dialog which has >>>>> been created with DialogSelectionType.NATIVE >>>>> it should return "null" as per spec >>>>> https://docs.oracle.com/javase/8/docs/api/java/awt/print/PrinterJob.html#pageDialog-javax.print.attribute.PrintRequestAttributeSet- >>>>> /[If the user cancels the dialog, the attributes will not reflect >>>>> any changes made by the user, and the return value will be null.] >>>>> >>>>> /We were returning PageFormat instead. Fixed to return null in >>>>> such case. >>>>> >>>>> Regards >>>>> Prasanta >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Nov 16 20:02:38 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Nov 2015 12:02:38 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5649E312.2010606@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> Message-ID: <564A365E.3030707@oracle.com> Hi Alexandr, One bug - we should be using LOGPIXELSY instead of X. Otherwise, the changes look OK except for the one question/issue which I don't know/remember the answer for: How does this interact with per-monitor APIs? I believe LOGPIXELSX will not change until the user logs off and back on even if the application is declared per-monitor aware. On the other hand, if we use the new 8.1 per-monitor DPI functions then we will be getting appropriate values for DPI that do change dynamically (they change instantaneously as the user modifies the DPI preferences in the CP). I don't think we need to worry about what happens when the CP settings change while we are running because this code is converting a pixel font size into a scalable font size and that should remain valid across all monitors and DPI changes. We are worried more about the case of the user changing the CP settings and then running a Java program before rebooting - where the LOGPIXELSX value is "stale" and only the new API produces the current value. The other question is, when we grab the indicated font size, is the API we query for the font size based upon the non-PM-aware LOGPIXELSX value? Or is it based upon a more dynamic PM-aware value? If it is dynamic then we will need to de-scale it by the dynamic DPI value. If it is not dynamic then LOGPIXELSX may be the right value to de-scale it even if the CP has been modified. In other words, are the platform APIs for font sizes static until reboot just like LOGPIXELSX? And I forget if we are already using the new APIs in the rest of the Windows HiDPI code...? In either case this will require some testing to see what happens as the CP values are modified dynamically (without logging out) in 8.1... ...jim On 11/16/15 6:07 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 > > - round is used instead of ceil > - inverted scales are used > > Thanks, > Alexandr. > > > On 10/30/2015 10:40 PM, Jim Graham wrote: >> In this case round may be better. ceil() is more for cases where you >> needed "at least X amount of room", but I don't think a font size is >> an "at least this much" kind of case. >> >> Also, I've been toying with the idea that use of ceil() and floor() in >> any DPI-adjustment equations should really be "ceil(val - epsilon)" or >> "floor(ceil + epsilon)" for some small value of epsilon chosen just >> large enough to prevent various round-off errors from affecting the >> outcome. One idea is for 1/256 as the value of epsilon since that >> could equate to the smallest measurable difference in terms of alpha >> or interpolation results (or 1/512 for "half the smallest quantum")... >> >> ...jim >> >> On 10/29/15 1:36 PM, Phil Race wrote: >>> size->cx = (int)ceil(size->cx / scale); >>> >>> >>> So if size->cx / scale works out to be 12.0001 you will round it up >>> to 13? >>> >>> Can you check what pixel size windows gives you in such a case ? >>> I'd be a little surprised if they did that rather than round. >>> >>> Is the SetFontProperty that does not accept a scale parameter still used >>> somewhere ? >>> >>> -phil. >>> >>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>> >>>>>> - Sergey's point about multi-mon should be checked out. >>>>> Windows 8.1 has option "Let me choose one scaling level for >>>>> all my >>>>> displays". >>>>> If I unset it I am able to change the size of all items. However, >>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI displays. >>>> >>>> This version looks fine, but I am sure it can be double checked on >>>> windows 10 at some moment as well. >>>> >>>> >>> > From philip.race at oracle.com Mon Nov 16 20:42:06 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 12:42:06 -0800 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8039412, , Stack overflow on Linux using DialogTypeSelection.NATIVE In-Reply-To: <56459E41.7070004@oracle.com> References: <563C885A.7080009@oracle.com> <5644E045.20409@oracle.com> <56459E41.7070004@oracle.com> Message-ID: <564A3F9E.6000204@oracle.com> On 11/13/2015 12:24 AM, prasanta sadhukhan wrote: > Hi Phil, > > On 11/13/2015 12:23 AM, Philip Race wrote: >> I am 99% sure this breaks the API on Windows on Mac. >> Did you test what it does there ? >> > It works on Windows as PrinterJob.pageDialog(attributes) calls > pageDialog(PageFormat page) in WPrinterJob.java which overrides > pageDialog(PageFormat) of RasterPrinterJob > It also works on Mac as PrinterJob.pageDialog(attributes) calls > pageDialog(PageFormat page) in CPrinterJob.java which overrides > pageDialog(PageFormat) of RasterPrinterJob > > I actually mistakenly mentioned down below that the check was added in > pageDialog(attributes) whereas actually > the temporary removal and addition was added in pageDialog(PageFormat) > so it only affects linux printing dialog. I see. So long as you have tested .. approved. -phil. >> Test has wild card imports again .. > Corrected wild card imports. Updated webrev is here: > http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.01/ > >> >> Also please add evaluation and explanation of the proposed fix into a >> public comment on the bug report before submitting for review. >> > Added public comment. > > Regards > Prasanta >> -phil. >> >> On 11/6/15, 3:00 AM, prasanta sadhukhan wrote: >>> Hi All, >>> >>> Please review a fix for jdk9. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039412 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.00/ >>> >>> Issue was seen in linux whereby if we call PrinterJob.pageDialog() >>> after PrinterJob.printDialog() it results in StackOverflowError if >>> DialogSelectionType is NATIVE. >>> >>> This was because pageDialog(attributes) was calling >>> pageDialog(pageformat) if it is DialogTypeSelection.NATIVE which >>> again calls pageDialog(attributes) >>> via this code >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l767 >>> >>> and >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l743 >>> >>> >>> I added a fix whereby in pageDialog(attributes)we check if it is >>> DialogTypeSelection.NATIVE and remove this attribute temporarily >>> before calling pageDialog(pageformat) >>> and restore the DialogTypeSelection.NATIVE after the call. >>> It is similar to solution done in >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l443 >>> >>> >>> Regards >>> Prasanta > From philip.race at oracle.com Mon Nov 16 20:51:31 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 12:51:31 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <5649E312.2010606@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> Message-ID: <564A41D3.5010202@oracle.com> That seems better. But one more question to get a point clarified. You are using getDesktopWindow() which is for the primary monitor. I assume that the 'inversion' results in the value being used to be independent of the monitor in a multi-mon situation and so when we move to a 2nd monitor that inverted size remains valid ? If so looks good to me. -phil. On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 > > - round is used instead of ceil > - inverted scales are used > > Thanks, > Alexandr. > > > On 10/30/2015 10:40 PM, Jim Graham wrote: >> In this case round may be better. ceil() is more for cases where you >> needed "at least X amount of room", but I don't think a font size is >> an "at least this much" kind of case. >> >> Also, I've been toying with the idea that use of ceil() and floor() >> in any DPI-adjustment equations should really be "ceil(val - >> epsilon)" or "floor(ceil + epsilon)" for some small value of epsilon >> chosen just large enough to prevent various round-off errors from >> affecting the outcome. One idea is for 1/256 as the value of epsilon >> since that could equate to the smallest measurable difference in >> terms of alpha or interpolation results (or 1/512 for "half the >> smallest quantum")... >> >> ...jim >> >> On 10/29/15 1:36 PM, Phil Race wrote: >>> size->cx = (int)ceil(size->cx / scale); >>> >>> >>> So if size->cx / scale works out to be 12.0001 you will round it up >>> to 13? >>> >>> Can you check what pixel size windows gives you in such a case ? >>> I'd be a little surprised if they did that rather than round. >>> >>> Is the SetFontProperty that does not accept a scale parameter still >>> used >>> somewhere ? >>> >>> -phil. >>> >>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>> >>>>>> - Sergey's point about multi-mon should be checked out. >>>>> Windows 8.1 has option "Let me choose one scaling level for >>>>> all my >>>>> displays". >>>>> If I unset it I am able to change the size of all items. >>>>> However, >>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI displays. >>>> >>>> This version looks fine, but I am sure it can be double checked on >>>> windows 10 at some moment as well. >>>> >>>> >>> > From james.graham at oracle.com Mon Nov 16 21:43:05 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Nov 2015 13:43:05 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8076545 Text size is twice bigger under Windows L&F on Win 8.1 with HiDPI display In-Reply-To: <564A41D3.5010202@oracle.com> References: <5596C117.1040806@oracle.com> <559DB2FB.5000208@oracle.com> <55A902D4.1050603@oracle.com> <563208A9.50702@oracle.com> <56328355.1010608@oracle.com> <5633C7C8.2030804@oracle.com> <5649E312.2010606@oracle.com> <564A41D3.5010202@oracle.com> Message-ID: <564A4DE9.1040102@oracle.com> Note that LOGPIXELSY is global and static between reboots so it doesn't really matter which monitor is used to get the value. Also, the issue is that the measurements are in pixels, so if we convert them into a resolution independent measurement then the rest of the scaling in the AWT/2D will be correct regardless of any given monitor's resolution. We just have to make sure the "de-pixelization" of the measurement is an apples-to-apples calculation. The question in my mind is whether the values they get from GetTheme*() and SPI_GETNONCLIENTMETRICS are relative to LOGPIXELSY, or the more recent Per-Monitor aware DPI APIs, or ...? It would be interesting to see what happens to those values when you change the DPI settings on Windows 8.1 and not reboot. If they stay constant until you reboot then LOGPIXELSY on the main screen would be the value to use to de-scale them... ...jim On 11/16/2015 12:51 PM, Phil Race wrote: > That seems better. But one more question to get a point clarified. > You are using getDesktopWindow() which is for the primary monitor. > I assume that the 'inversion' results in the value being used to be > independent > of the monitor in a multi-mon situation and so when we move to a 2nd > monitor > that inverted size remains valid ? > > If so looks good to me. > > -phil. > > On 11/16/2015 06:07 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8076545/webrev.02 >> >> - round is used instead of ceil >> - inverted scales are used >> >> Thanks, >> Alexandr. >> >> >> On 10/30/2015 10:40 PM, Jim Graham wrote: >>> In this case round may be better. ceil() is more for cases where you >>> needed "at least X amount of room", but I don't think a font size is >>> an "at least this much" kind of case. >>> >>> Also, I've been toying with the idea that use of ceil() and floor() >>> in any DPI-adjustment equations should really be "ceil(val - >>> epsilon)" or "floor(ceil + epsilon)" for some small value of epsilon >>> chosen just large enough to prevent various round-off errors from >>> affecting the outcome. One idea is for 1/256 as the value of epsilon >>> since that could equate to the smallest measurable difference in >>> terms of alpha or interpolation results (or 1/512 for "half the >>> smallest quantum")... >>> >>> ...jim >>> >>> On 10/29/15 1:36 PM, Phil Race wrote: >>>> size->cx = (int)ceil(size->cx / scale); >>>> >>>> >>>> So if size->cx / scale works out to be 12.0001 you will round it up >>>> to 13? >>>> >>>> Can you check what pixel size windows gives you in such a case ? >>>> I'd be a little surprised if they did that rather than round. >>>> >>>> Is the SetFontProperty that does not accept a scale parameter still >>>> used >>>> somewhere ? >>>> >>>> -phil. >>>> >>>> On 10/29/2015 04:53 AM, Sergey Bylokhov wrote: >>>>> On 17.07.15 16:27, Alexander Scherbatiy wrote: >>>>>>> >>>>>>> - Sergey's point about multi-mon should be checked out. >>>>>> Windows 8.1 has option "Let me choose one scaling level for >>>>>> all my >>>>>> displays". >>>>>> If I unset it I am able to change the size of all items. >>>>>> However, >>>>>> the DPI which returns GetDPIForMonitor is still 2 on HiDPI displays. >>>>> >>>>> This version looks fine, but I am sure it can be double checked on >>>>> windows 10 at some moment as well. >>>>> >>>>> >>>> >> > From philip.race at oracle.com Mon Nov 16 21:52:00 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 13:52:00 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <3ea69749-8b12-43ca-bb53-3db53eb8d26b@default> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> <5644DD22.2080205@oracle.com> <3ea69749-8b12-43ca-bb53-3db53eb8d26b@default> Message-ID: <564A5000.6040202@oracle.com> This one reads like it should be obvious but I find it less so .. The unsatisfying part is that we do not seem to know what caused the IOException in the customer case. Andrew came up with a way to reproduce the symptoms but we really don't know what caused the exception in the case of the submitter. It does not seem likely he was 'deliberately' throwing an exception to mess up his own application. I just found this : https://bugs.openjdk.java.net/browse/JDK-8041746 The interesting part is that this bug (the one you are working on) the submitter also wrote that he was using "a ServletOutputStream" So consequently I wonder if it was something like what is described in 8041746 is going on here. It could explain how he sees 7 out of 20 fail. Please take a look at that one to have a think about it. Would your fix help that real world case ? -phil. On 11/12/2015 08:11 PM, Jayathirth D V wrote: > > Hi Phil, > > I have added public evaluation in bug. Please review. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Friday, November 13, 2015 12:11 AM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Please add a *public* evaluation to the bug report. I will look at it > more then .. > > -phil. > > On 11/6/15, 2:20 AM, Jayathirth D V wrote: > > Hi Prasanta, > > As discussed, only in case of write_IDAT there is finally block > which calls ios.finish() which internally calls seek() with > improper startPos. In other cases we are not trying to access > improper startPos because there is no call to ios.finish(). We can > verify this behavior by changing logic where we throw IOException > in test case. > > And I have modified test to not catch IOBE as per your suggestion. > Please find updated Webrev link: > > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Friday, November 06, 2015 2:45 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Hi Jay, > > looks ok but > I guess you need to do the same for finish() method too in similar > way you did for finishChunk() as finish() is called from > write_IHDR, write_CHRM etc and it calls flushBefore(). > Also, I guess you should not consume IOB Exception and let it be > thrown to user instead of RuntimeException after catching IOBE. > > Regards > Prasanta > > On 11/5/2015 5:25 PM, Jayathirth D V wrote: > > Hello All, > > Please review following fix in jdk9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 > > Webrev : > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ > > > Bug : IndexOutOfBoundsException when drawing PNGs > > Root cause : When user intentionally throws IO Exception while > write is happening. > We call ios.finish() in finally > block of write_IDAT() which internally goes to finishChunk(). > But the startPos of the chunk is still pointing to present > IDAT chunk but flushedPos(streamPos) is pointing to end of > IDAT chunk. > So in finishChunk(), startPos will > be less than flushedPos. This is causing > IndexOutOfBoundException in stream.seek() and cache is not closed. > > Solution : If IOException is thrown by user, catch the > exception while write is happening and update startPos to > streamPos. So that when seek() happens in finishChunk() we > don't see IndexOutOfBoundsException and cache is closed properly. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Nov 16 21:53:38 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 16 Nov 2015 13:53:38 -0800 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <563C5B77.2060607@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> <563721AB.90407@oracle.com> <563A93B8.1010202@oracle.com> <563C5B77.2060607@oracle.com> Message-ID: <564A5062.5070301@oracle.com> Would it not be better to be explicit in this so as not to leave it to chance ? -phil. On 11/05/2015 11:49 PM, prasanta sadhukhan wrote: > Hi Phil, > > On 11/5/2015 4:54 AM, Philip Race wrote: >> This does not look right to me. Who knows what data is on the canvas ? >> it is not clear that it is 'blank'. It could have data from a >> previous glyph .. I am not >> sure how you know for sure. I can see that canvas is re-used. There >> is reference >> to a "global shared canvas". >> And the actual function you invoke is one of two : one for grey and >> one for lcd and >> looking at the grey one CGGI_CopyImageFromCanvasToAlphaInfo) >> it utilises info->width and info->height which can't be NaN because they >> are uint16 but I don't know if they are valid .. and is the "image" >> field >> allocated to be 0 length ? > info->width & height is coming out to be 0 in case of NaN transform > therefore "image" field will be of 0 length so "empty" glyph will be > copied when we copy the "glyph image" from canvas (no matter what is > there in canvas) to info->image via this code > http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m#l294 > > > > size_t destRow = y * destRowWidth; > size_t srcRow = y * srcRowWidth; > size_t x; > for (x = 0; x < destRowWidth; x++) { > UInt32 p = src[srcRow + x]; > dest[destRow + x] = CGGI_ConvertBWPixelToByteGray(p); > > where destRowWidth = destRow = info->width will be 0 so dest = > info->image will be of 0 length > > Regards > Prasanta >> Could you step through how this is all guaranteed >> to be safe/correct ? >> >> -phil. >> >> On 11/2/15, 12:41 AM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> I have modified as per your review to populate GlyphInfo with >>> "empty" glyph >>> and also moved your existing test to "open" >>> I also added a Infinite Transform test along with your NaN transform >>> just incase (in fact Sergey informally asked me to check) >>> >>> http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ >>> >>> Regards >>> Prasanta >>> On 10/30/2015 1:03 AM, Phil Race wrote: >>>> Should this new check go before this : >>>> >>>> CGGI_ClearCanvas(canvas, info); >>>> >>>> since it is using info which is where you get NaN from. >>>> >>>> >>>> And should we then populate the returned canvas and info to >>>> ensure that we return an "empty" glyph rather than garbage values ? >>>> It is not clear to me that this is occurring. >>>> >>>> Why does the bug report not contain the evaluation below ? >>>> Also why is there a new test ? I would expect SQE would >>>> want to run the existing test to verify this fix. >>>> Should we not just open the existing test ? >>>> >>>> >>>> -phil. >>>> >>>> On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >>>>> Gentle reminder for review >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>>>>> Hello All, >>>>>> >>>>>> Please review a fix for jdk9 >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>>>>> >>>>>> drawString takes long time in mac native call >>>>>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>>>>> translated to x & y being NaN. >>>>>> Fix is to prevent calling mac api for such invalid usage. >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>> >>>> >>> > From james.graham at oracle.com Mon Nov 16 23:05:38 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Nov 2015 15:05:38 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <564613DD.8070005@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> <5643D04B.7030504@oracle.com> <564613DD.8070005@oracle.com> Message-ID: <564A6142.4010000@oracle.com> I ran SwingSet2 and JDK-8069348 immediately jumped out as being broken to the point where SwingSet2 was not usable. We should definitely make that a high priority to fix ASAP. There were a couple of other very minor rendering issues, but they didn't really affect usability like that bug... ...jim On 11/13/2015 8:46 AM, Alexander Scherbatiy wrote: > > Hello, > > I have filled additional issues which has been discussed on the review: > JDK-8076545 Text size is twice bigger under Windows L&F on Win 8.1 > with HiDPI display > JDK-8142966 Wrong cursor position in text components on HiDPI display > JDK-8142961 Position, size and distance scaling for HiDPI graphics > support > JDK-8142963 Better transformImage support for HiDPI images > JDK-8069348 SunGraphics2D.copyArea() does not properly work for > scaled graphics > JDK-8142965 Consider the case where MRI can contains VolatileImage > > Thanks, > Alexandr. > > On 11/12/2015 2:33 AM, Jim Graham wrote: >> Hi Alexandr, >> >> On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: >>> On 11/10/2015 10:41 PM, Jim Graham wrote: >>>> In drawHiDPIImage, in the VolatileImage case you ignore the transform, >>>> but I suppose that is OK because you pass it through to the >>>> scaleImage() case. However if it came in with a transform then the >>>> asserts at the top of scaleImage may fail? Maybe it would be better >>>> to actually handle the "non-0,0,iw,ih" case rather than assert that it >>>> doesn't exist? >>> The only case where xform is not null is the drawImage(img, xform, >>> observer) method which always use zero x, y and the same src and dst >>> width/height. >>> Could we move the full support for a resolution variant >>> transformation to a separate fix? >> >> Ah, sorry, I was reading the old webrev.02 and also mixing up >> s[xy][12] (which are scaled) with d[xy][12] (which are the ones being >> compared). You are correct there. >> >> The new version in webrev.03 is a little clunky with having to modify >> the current transform, but it looks correct. >> >>>> BIGC.getConfig() - I don't see where you put the scale into the BIGC >>>> when you create it. Shouldn't the constructor with scales be used at >>>> line 73? >>> >>> It is updated in the latest webrev: >>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 >>> which has been sent to the review: >>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html >> >> Found the webrev.03 and it is already fixed as you say. >> >>>> SGE.getScaleFactor() - suggestion: perhaps ignore an optional final >>>> suffix "x" in the regular scale case so that they can say "=3.0x" to >>>> mean the same as "=3"? >>> >>> It should also be updated in the latest webrev. >> >> Found it. Looks good... >> >>>> Looks almost good to go from my perspective. What is the plan for >>>> Swing testing and fixing those bugs? >> >> The latest fix looks good to go. I was hoping to build it and test >> some swing apps, but I don't have a decent build environment ready to >> go yet. We need to be proactive about understanding how this affects >> Swing so that we can inform our developers about any changes they may >> need to make to look good under HiDPI and/or modify the approach to >> handle it ourselves... >> >> ...jim > From jennifer.godinez at oracle.com Mon Nov 16 23:53:20 2015 From: jennifer.godinez at oracle.com (Jennifer Godinez) Date: Mon, 16 Nov 2015 15:53:20 -0800 Subject: [OpenJDK 2D-Dev] 7162125: [macosx] A font has different behaviour for ligatures depending on its creation mode In-Reply-To: <5646637D.40403@oracle.com> References: <564579C7.9070604@oracle.com> <5646637D.40403@oracle.com> Message-ID: <564A6C70.2030200@oracle.com> Looks good. Approved. Jennifer On 11/13/2015 2:26 PM, Philip Race wrote: > I have managed to create a regression test that I think I can trust on > OS X > Updated webrev :- http://cr.openjdk.java.net/~prr/7162125.1 > > -phil. > > On 11/12/15, 9:48 PM, Philip Race wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-7162125 >> Fix: http://cr.openjdk.java.net/~prr/7162125/ >> >> The problem is that complex text layout and accompanying typographic >> support >> is largely limping along on OS X and then only thanks to some canonical >> tables that the ICU library has. >> >> The bug is that the internal font "peer" that passes the font tables >> containing the necessary information for OpenType (and AAT) layout >> does not implement the necessary functions. So there is no way to >> get the information that the font itself contains, resulting in >> incorrect >> rendering. >> >> The fix needs to be to add to the osx "CFont" class the necessary >> code to pass that information. That is not so hard. >> >> But there is an additional complication that the OS X code uses >> "fallback" or "substitution" or "cascading" fonts and so a font >> like "Lucida Grande" might report that it supports code points >> from Indic scripts when it does not. It does this by reporting >> negative glyph codes for such cases and fixes it up in the final >> rendering step. The problem with that is that layout needs to >> use the font-specific tables and this subverts that. We need >> to know for sure which code points are supported and split >> into runs of text that the font supports. So we need to find >> the real fonts that the CFont uses. In core text this is obtainable >> as the cascading font list. We can get this and construct a >> CompositeFont and make its glyph mapper check that there >> are no *negative* glyph codes not just no zero ones. >> >> Now we can give layout proper runs and tables. >> The final bit is that rendering needs to also know that if it >> is passed a font that might implement FontSubstition that >> it needs to expect that layout returned glyph codes that >> are intended to be used with the Composite. >> >> A reliable regression test is tricky. I have looked for a simple >> code point sequence that an installed OS X font provides that I can >> "measure" to see that the ligature forms but have not found one. >> >> I have however tested using the font provided in >> https://bugs.openjdk.java.net/browse/JDK-8139741 >> but I cannot check that in. >> >> -phil. >> >> >> >> >> >> From james.graham at oracle.com Mon Nov 16 23:56:09 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 16 Nov 2015 15:56:09 -0800 Subject: [OpenJDK 2D-Dev] [9] Review request for 8073320 Windows HiDPI Graphics support In-Reply-To: <564A6142.4010000@oracle.com> References: <56012064.2020800@oracle.com> <56185858.3090202@oracle.com> <5627944A.7010802@oracle.com> <5627A3F7.2000601@oracle.com> <562900B8.7060503@oracle.com> <56424856.3060007@oracle.com> <564321C0.9030106@oracle.com> <5643D04B.7030504@oracle.com> <564613DD.8070005@oracle.com> <564A6142.4010000@oracle.com> Message-ID: <564A6D19.5020506@oracle.com> Note that the test case in JDK-8069348 seems to work OK for a scaled graphics (it actually fails only if I set the uiScale to 1 for some reason), but Swing scrolling is completely broken. I dug down to the call to D3D->StretchRect and it was returning D3DERR_INVALIDCALL and simply not doing any copy at all unless the scale was 1. It was not throwing that error for the test case in the bug report, though... ...jim On 11/16/2015 3:05 PM, Jim Graham wrote: > I ran SwingSet2 and JDK-8069348 immediately jumped out as being broken > to the point where SwingSet2 was not usable. We should definitely make > that a high priority to fix ASAP. There were a couple of other very > minor rendering issues, but they didn't really affect usability like > that bug... > > ...jim > > On 11/13/2015 8:46 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> I have filled additional issues which has been discussed on the >> review: >> JDK-8076545 Text size is twice bigger under Windows L&F on Win 8.1 >> with HiDPI display >> JDK-8142966 Wrong cursor position in text components on HiDPI >> display >> JDK-8142961 Position, size and distance scaling for HiDPI graphics >> support >> JDK-8142963 Better transformImage support for HiDPI images >> JDK-8069348 SunGraphics2D.copyArea() does not properly work for >> scaled graphics >> JDK-8142965 Consider the case where MRI can contains VolatileImage >> >> Thanks, >> Alexandr. >> >> On 11/12/2015 2:33 AM, Jim Graham wrote: >>> Hi Alexandr, >>> >>> On 11/11/15 3:08 AM, Alexander Scherbatiy wrote: >>>> On 11/10/2015 10:41 PM, Jim Graham wrote: >>>>> In drawHiDPIImage, in the VolatileImage case you ignore the transform, >>>>> but I suppose that is OK because you pass it through to the >>>>> scaleImage() case. However if it came in with a transform then the >>>>> asserts at the top of scaleImage may fail? Maybe it would be better >>>>> to actually handle the "non-0,0,iw,ih" case rather than assert that it >>>>> doesn't exist? >>>> The only case where xform is not null is the drawImage(img, >>>> xform, >>>> observer) method which always use zero x, y and the same src and dst >>>> width/height. >>>> Could we move the full support for a resolution variant >>>> transformation to a separate fix? >>> >>> Ah, sorry, I was reading the old webrev.02 and also mixing up >>> s[xy][12] (which are scaled) with d[xy][12] (which are the ones being >>> compared). You are correct there. >>> >>> The new version in webrev.03 is a little clunky with having to modify >>> the current transform, but it looks correct. >>> >>>>> BIGC.getConfig() - I don't see where you put the scale into the BIGC >>>>> when you create it. Shouldn't the constructor with scales be used at >>>>> line 73? >>>> >>>> It is updated in the latest webrev: >>>> http://cr.openjdk.java.net/~alexsch/8073320/webrev.03 >>>> which has been sent to the review: >>>> http://mail.openjdk.java.net/pipermail/2d-dev/2015-November/005814.html >>> >>> Found the webrev.03 and it is already fixed as you say. >>> >>>>> SGE.getScaleFactor() - suggestion: perhaps ignore an optional final >>>>> suffix "x" in the regular scale case so that they can say "=3.0x" to >>>>> mean the same as "=3"? >>>> >>>> It should also be updated in the latest webrev. >>> >>> Found it. Looks good... >>> >>>>> Looks almost good to go from my perspective. What is the plan for >>>>> Swing testing and fixing those bugs? >>> >>> The latest fix looks good to go. I was hoping to build it and test >>> some swing apps, but I don't have a decent build environment ready to >>> go yet. We need to be proactive about understanding how this affects >>> Swing so that we can inform our developers about any changes they may >>> need to make to look good under HiDPI and/or modify the approach to >>> handle it ourselves... >>> >>> ...jim >> From prasanta.sadhukhan at oracle.com Tue Nov 17 06:12:17 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 17 Nov 2015 11:42:17 +0530 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <564A5062.5070301@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> <563721AB.90407@oracle.com> <563A93B8.1010202@oracle.com> <563C5B77.2060607@oracle.com> <564A5062.5070301@oracle.com> Message-ID: <564AC541.6080403@oracle.com> Hi Phil, I have updated webrev to explicitly set glyph image width/height to be 0 in case of NaN transform. Could you please review it? http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.02/ Regards Prasanta On 11/17/2015 3:23 AM, Phil Race wrote: > Would it not be better to be explicit in this so as not to leave it to > chance ? > > -phil. > > On 11/05/2015 11:49 PM, prasanta sadhukhan wrote: >> Hi Phil, >> >> On 11/5/2015 4:54 AM, Philip Race wrote: >>> This does not look right to me. Who knows what data is on the canvas ? >>> it is not clear that it is 'blank'. It could have data from a >>> previous glyph .. I am not >>> sure how you know for sure. I can see that canvas is re-used. There >>> is reference >>> to a "global shared canvas". >>> And the actual function you invoke is one of two : one for grey and >>> one for lcd and >>> looking at the grey one CGGI_CopyImageFromCanvasToAlphaInfo) >>> it utilises info->width and info->height which can't be NaN because >>> they >>> are uint16 but I don't know if they are valid .. and is the "image" >>> field >>> allocated to be 0 length ? >> info->width & height is coming out to be 0 in case of NaN transform >> therefore "image" field will be of 0 length so "empty" glyph will be >> copied when we copy the "glyph image" from canvas (no matter what is >> there in canvas) to info->image via this code >> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m#l294 >> >> >> >> size_t destRow = y * destRowWidth; >> size_t srcRow = y * srcRowWidth; >> size_t x; >> for (x = 0; x < destRowWidth; x++) { >> UInt32 p = src[srcRow + x]; >> dest[destRow + x] = CGGI_ConvertBWPixelToByteGray(p); >> >> where destRowWidth = destRow = info->width will be 0 so dest = >> info->image will be of 0 length >> >> Regards >> Prasanta >>> Could you step through how this is all guaranteed >>> to be safe/correct ? >>> >>> -phil. >>> >>> On 11/2/15, 12:41 AM, prasanta sadhukhan wrote: >>>> Hi Phil, >>>> >>>> I have modified as per your review to populate GlyphInfo with >>>> "empty" glyph >>>> and also moved your existing test to "open" >>>> I also added a Infinite Transform test along with your NaN >>>> transform just incase (in fact Sergey informally asked me to check) >>>> >>>> http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ >>>> >>>> Regards >>>> Prasanta >>>> On 10/30/2015 1:03 AM, Phil Race wrote: >>>>> Should this new check go before this : >>>>> >>>>> CGGI_ClearCanvas(canvas, info); >>>>> >>>>> since it is using info which is where you get NaN from. >>>>> >>>>> >>>>> And should we then populate the returned canvas and info to >>>>> ensure that we return an "empty" glyph rather than garbage values ? >>>>> It is not clear to me that this is occurring. >>>>> >>>>> Why does the bug report not contain the evaluation below ? >>>>> Also why is there a new test ? I would expect SQE would >>>>> want to run the existing test to verify this fix. >>>>> Should we not just open the existing test ? >>>>> >>>>> >>>>> -phil. >>>>> >>>>> On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >>>>>> Gentle reminder for review >>>>>> >>>>>> Regards >>>>>> Prasanta >>>>>> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>>>>>> Hello All, >>>>>>> >>>>>>> Please review a fix for jdk9 >>>>>>> >>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>>>>>> >>>>>>> drawString takes long time in mac native call >>>>>>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>>>>>> translated to x & y being NaN. >>>>>>> Fix is to prevent calling mac api for such invalid usage. >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>> >>>>> >>>> >> > From jayathirth.d.v at oracle.com Tue Nov 17 09:11:52 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 17 Nov 2015 01:11:52 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <564A5000.6040202@oracle.com> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> <5644DD22.2080205@oracle.com> <3ea69749-8b12-43ca-bb53-3db53eb8d26b@default> <564A5000.6040202@oracle.com> Message-ID: <73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default> Hi Phil, Thanks for pointing to JDK-8041746 . My observations: I think with Andrew's test case we are able to identify the problem submitter might have faced in JDK-6967419 . By deliberately throwing exception at count 30000L we are trying to reproduce scenario of possible IOException where client is closing the socket(probably because of communication problem between client & server) and IDAT chunk is being written. If we change count to any other number(like 10L) which relates to writing of data apart from IDAT chunk we don't see any issue(no exception and cache is closed properly). This might explain why submitter is seeing 7 out of 20 fail. Also by using the test case we are able to see flushedPos going past by 4 bytes to Pos when ios.close() is called as mentioned by submitter in JDK-6967419. So catching the IOException and updating 'startPos' value, will not result in IndexOutOfBoundsException and ios.close() will be performed properly. Please let us know your inputs. Thanks, Jay From: Phil Race Sent: Tuesday, November 17, 2015 3:22 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs This one reads like it should be obvious but I find it less so .. The unsatisfying part is that we do not seem to know what caused the IOException in the customer case. Andrew came up with a way to reproduce the symptoms but we really don't know what caused the exception in the case of the submitter. It does not seem likely he was 'deliberately' throwing an exception to mess up his own application. I just found this : https://bugs.openjdk.java.net/browse/JDK-8041746 The interesting part is that this bug (the one you are working on) the submitter also wrote that he was using "a ServletOutputStream" So consequently I wonder if it was something like what is described in 8041746 is going on here. It could explain how he sees 7 out of 20 fail. Please take a look at that one to have a think about it. Would your fix help that real world case ? -phil. On 11/12/2015 08:11 PM, Jayathirth D V wrote: Hi Phil, I have added public evaluation in bug. Please review. Thanks, Jay From: Philip Race Sent: Friday, November 13, 2015 12:11 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Please add a *public* evaluation to the bug report. I will look at it more then .. -phil. On 11/6/15, 2:20 AM, Jayathirth D V wrote: Hi Prasanta, As discussed, only in case of write_IDAT there is finally block which calls ios.finish() which internally calls seek() with improper startPos. In other cases we are not trying to access improper startPos because there is no call to ios.finish(). We can verify this behavior by changing logic where we throw IOException in test case. And I have modified test to not catch IOBE as per your suggestion. Please find updated Webrev link: HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.01/"http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ Thanks, Jay From: prasanta sadhukhan Sent: Friday, November 06, 2015 2:45 PM To: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs Hi Jay, looks ok but I guess you need to do the same for finish() method too in similar way you did for finishChunk() as finish() is called from write_IHDR, write_CHRM etc and it calls flushBefore(). Also, I guess you should not consume IOB Exception and let it be thrown to user instead of RuntimeException after catching IOBE. Regards Prasanta On 11/5/2015 5:25 PM, Jayathirth D V wrote: Hello All, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Erchamyal/jay/6967419/webrev.00/"http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ Bug : IndexOutOfBoundsException when drawing PNGs Root cause : When user intentionally throws IO Exception while write is happening. We call ios.finish() in finally block of write_IDAT() which internally goes to finishChunk(). But the startPos of the chunk is still pointing to present IDAT chunk but flushedPos(streamPos) is pointing to end of IDAT chunk. So in finishChunk(), startPos will be less than flushedPos. This is causing IndexOutOfBoundException in stream.seek() and cache is not closed. Solution : If IOException is thrown by user, catch the exception while write is happening and update startPos to streamPos. So that when seek() happens in finishChunk() we don't see IndexOutOfBoundsException and cache is closed properly. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Tue Nov 17 11:18:13 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Tue, 17 Nov 2015 03:18:13 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8039412, , Stack overflow on Linux using DialogTypeSelection.NATIVE In-Reply-To: <564AB939.6030805@oracle.com> References: <564A3F9E.6000204@oracle.com> <564AB939.6030805@oracle.com> Message-ID: <90b07074-119f-45b1-9b1e-1abedffd2c35@default> The fix looks good to me. ? Regards, Rajeev Chamyal Subject: Re: [9] RFR: JDK-8039412,,Stack overflow on Linux using DialogTypeSelection.NATIVE Date: Mon, 16 Nov 2015 12:42:06 -0800 From: Phil Race HYPERLINK "mailto:philip.race at oracle.com" To: prasanta sadhukhan HYPERLINK "mailto:prasanta.sadhukhan at oracle.com" CC: Rajeev Chamyal HYPERLINK "mailto:rajeev.chamyal at oracle.com", HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net HYPERLINK "mailto:2d-dev at openjdk.java.net"<2d-dev at openjdk.java.net> ? On 11/13/2015 12:24 AM, prasanta sadhukhan wrote: > Hi Phil, >? > On 11/13/2015 12:23 AM, Philip Race wrote: >> I am 99% sure this breaks the API on Windows on Mac. >> Did you test what it does there ? >>? > It works on Windows as PrinterJob.pageDialog(attributes) calls > pageDialog(PageFormat page) in WPrinterJob.java which overrides > pageDialog(PageFormat) of RasterPrinterJob > It also works on Mac as PrinterJob.pageDialog(attributes) calls > pageDialog(PageFormat page) in CPrinterJob.java which overrides > pageDialog(PageFormat) of RasterPrinterJob >? > I actually mistakenly mentioned down below that the check was added in > pageDialog(attributes) whereas actually > the temporary removal and addition was added in pageDialog(PageFormat) > so it only affects linux printing dialog. ? ? I see. So long as you have tested .. approved. ? -phil. ? >> Test has wild card imports again .. > Corrected wild card imports. Updated webrev is here: > http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.01/ >? >>? >> Also please add evaluation and explanation of the proposed fix into a >> public comment on the bug report before submitting for review. >>? > Added public comment. >? > Regards > Prasanta >> -phil. >>? >> On 11/6/15, 3:00 AM, prasanta sadhukhan wrote: >>> Hi All, >>>? >>> Please review a fix for jdk9. >>>? >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8039412 >>> webrev: http://cr.openjdk.java.net/~psadhukhan/8039412/webrev.00/ >>>? >>> Issue was seen in linux whereby if we call PrinterJob.pageDialog() >>> after PrinterJob.printDialog() it results in StackOverflowError if >>> DialogSelectionType is NATIVE. >>>? >>> This was because pageDialog(attributes) was calling >>> pageDialog(pageformat) if it is DialogTypeSelection.NATIVE which >>> again calls pageDialog(attributes) >>> via this code >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l767 >>>? >>> and >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#l743 >>>? >>>? >>> I added a fix whereby in pageDialog(attributes)we check if it is >>> DialogTypeSelection.NATIVE and remove this attribute temporarily >>> before calling pageDialog(pageformat) >>> and restore the DialogTypeSelection.NATIVE after the call. >>> It is similar to solution done in >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#l443 >>>? >>>? >>> Regards >>> Prasanta >? ? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Nov 17 16:20:27 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 17 Nov 2015 19:20:27 +0300 Subject: [OpenJDK 2D-Dev] Review Request: Small tweak in the DrawImage.java In-Reply-To: <56464B84.5010500@oracle.com> References: <56449806.5090703@oracle.com> <5644FA8A.1050101@oracle.com> <56450A81.3070001@oracle.com> <564517BD.7000105@oracle.com> <56464417.2000300@oracle.com> <56464B84.5010500@oracle.com> Message-ID: <564B53CB.7030907@oracle.com> Bug filed: 8143150: DrawImagePipe can skip some unnecessary blits https://bugs.openjdk.java.net/browse/JDK-8143150 On 13.11.15 23:43, Jim Graham wrote: > Looks good! > > ...jim > > On 11/13/2015 12:12 PM, Sergey Bylokhov wrote: >> On 13.11.15 1:50, Jim Graham wrote: >>>> I can add a comment that this code is for performance, what do you >>>> think? >>> >>> I'd like to see that, was there an updated diff? In either case, I >>> don't think we should disturb the comment and test at the top, we should >>> just add additional checks down below where you have them now... >> >> The code for w/h was reverted. Probably I will try change it later in >> another fix, after verification of our java blits and the fix for >> JDK-4783274. >> >> http://cr.openjdk.java.net/~serb/perf/DrawImageItself.02/src/java.desktop/share/classes/sun/java2d/pipe/DrawImage.java.sdiff.html >> >> >> -- Best regards, Sergey. From philip.race at oracle.com Wed Nov 18 00:05:33 2015 From: philip.race at oracle.com (Philip Race) Date: Tue, 17 Nov 2015 16:05:33 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 Message-ID: <564BC0CD.7080207@oracle.com> Webrev : http://cr.openjdk.java.net/~prr/8143177/ Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 This webrev contains the changes accumulated in the harfbuzz project forest that migrate JDK from using ICU for opentype font layout to harfbuzz for the same. The change does not introduce API. It is mostly adding the harfbuzz library. The ICU library remains there but is no longer the default. Eventually (not necessarily in 9) it may be removed once we are comfortable with harfbuzz. You may select ICU by using -Dsun.font.layoutengine=icu You may see which layout engine is in use by using -Dsun.font.layoutengine.verbose=true it will print either "Using harfbuzz", or "Using ICU". The change has no impact on typical Latin script rendering but is a big advance for complex scripts and also applies if you select kerning or ligatures for Latin. However the latter is only detectable if the font implements support for these. By "big advance" I mean that ICU has not been updated to recognise recent opentype features. So harfbuzz should fix a number of things but unexpected changes that look wrong should be reported so we can investigate. To use harfbuzz we invoke its shaper and we provide a way to get jdk font information. This means that we do not need a different layer depending on whether freetype or t2k is used. It also enables some caching in the JDK font layer. On macosx harfbuzz does not natively read the AAT tables but will invoke CoreText. This does mean that an AAT font installed on Linux would not be processed but this is not a significant issue since AAT fonts are not found other than on macosx. The majority of the files in the webrev are harfbuzz itself, changed only to comply with JDK whitespace rules. Reviewers should probably concentrate on all of the rest. I've listed it so that all those files are at the beginning and you can ignore all those that follow that are in the "harfbuzz" directory. The harfbuzz version used here is 1.0.6 which is the latest source release (at the time of writing). We expect to update this to keep reasonably current. I would like to push this in on Friday, but at the very latest Monday because of the upcoming Feature Complete date so there are a couple of days to make small tweaks for serious problems but there will be plenty of time after integration to fix remaining problems. -phil. From Sergey.Bylokhov at oracle.com Wed Nov 18 15:09:03 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Nov 2015 18:09:03 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564BC0CD.7080207@oracle.com> References: <564BC0CD.7080207@oracle.com> Message-ID: <564C948F.6010400@oracle.com> Hi, Phil. Not an expert here, just a few notes: - Copyright is missing: hb-jdk-font.cc, hb-jdk.h - HBShaper.c: Do we need a code at 268? probably we can add some todo or remove it? On 18.11.15 3:05, Philip Race wrote: > Webrev : http://cr.openjdk.java.net/~prr/8143177/ > Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 > > This webrev contains the changes accumulated in the harfbuzz project forest > that migrate JDK from using ICU for opentype font layout to harfbuzz for > the same. > > The change does not introduce API. It is mostly adding the harfbuzz > library. > The ICU library remains there but is no longer the default. > Eventually (not necessarily in 9) it may be removed once we are comfortable > with harfbuzz. > You may select ICU by using -Dsun.font.layoutengine=icu > > You may see which layout engine is in use by using > -Dsun.font.layoutengine.verbose=true > it will print either "Using harfbuzz", or "Using ICU". > > The change has no impact on typical Latin script rendering but is a big > advance > for complex scripts and also applies if you select kerning or ligatures > for Latin. > However the latter is only detectable if the font implements support for > these. > By "big advance" I mean that ICU has not been updated to recognise > recent opentype features. > So harfbuzz should fix a number of things but unexpected changes that > look wrong > should be reported so we can investigate. > > To use harfbuzz we invoke its shaper and we provide a way to get jdk > font information. > This means that we do not need a different layer depending on whether > freetype or t2k > is used. It also enables some caching in the JDK font layer. > > On macosx harfbuzz does not natively read the AAT tables but will invoke > CoreText. > This does mean that an AAT font installed on Linux would not be > processed but > this is not a significant issue since AAT fonts are not found other than > on macosx. > > The majority of the files in the webrev are harfbuzz itself, changed > only to comply > with JDK whitespace rules. Reviewers should probably concentrate on all > of the rest. > I've listed it so that all those files are at the beginning and you can > ignore all those > that follow that are in the "harfbuzz" directory. > > The harfbuzz version used here is 1.0.6 which is the latest source > release (at the time of writing). > We expect to update this to keep reasonably current. > > I would like to push this in on Friday, but at the very latest Monday > because of the > upcoming Feature Complete date so there are a couple of days to make small > tweaks for serious problems but there will be plenty of time after > integration to fix > remaining problems. > > -phil. > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Wed Nov 18 17:11:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Wed, 18 Nov 2015 20:11:36 +0300 Subject: [OpenJDK 2D-Dev] Duplicated (or better multiplicated) image-decoder resolvers in openjdk In-Reply-To: <56336CE6.2010106@redhat.com> References: <56336CE6.2010106@redhat.com> Message-ID: <564CB148.90300@oracle.com> Hi, Jiri. This question also related to 2d area(cc) I think it is possible to use the PNGImageReader(spi) instead of sun.awt.PNGImageDecoder, which will allow automatically handle the nondefault image formats. But as far as I know there are no plan to do it in jdk9. On 30.10.15 16:13, Jiri Vanek wrote: > Hello! > > Recently I was doing ico imagereader-spi provider for icedtea-web > (which is javaws (and plugin) implementation for openjdk) > Yes, ico is stupid, but is in web standards so having its support is > just natural. However, providing spi did not solved the problem i was > bugged for. > > After small debugging why, I found that eg SunToolkit.createImage and > relatives - which are quite heavily used, do not honour ImageIO SPIs and > are going by its own way: > > > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/FileImageSource.java#l50 > > for file > and > http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/InputStreamImageSource.java#l213 > > for stream > > Well maybe its legacy bourden, but it is reimplementing what image SPIs > providers via (apis canDecodeInput[2]) do. Long story short - > reimplementing wheel and duplicated (very duplicated) code. > > I wonted to ask, if there are any plans in jdk9 to fix this. If no, what > can I do to make it happen. > > > Thanx! > J. > > > [2] > https://docs.oracle.com/javase/7/docs/api/javax/imageio/spi/ImageReaderSpi.html#canDecodeInput%28java.lang.Object%29 > > https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageReader.html -- Best regards, Sergey. From jvanek at redhat.com Wed Nov 18 17:17:16 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 18 Nov 2015 18:17:16 +0100 Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <56449312.2000005@oracle.com> References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com> <56449312.2000005@oracle.com> Message-ID: <564CB29C.10200@redhat.com> On 11/12/2015 02:24 PM, Sergey Bylokhov wrote: > Hi, Jiri. > This is a valid point, did you file a new CR for this issue? > Hello! here it is: https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/ Patch: https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/ and reprodcuer https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java Reproducer can be easily turned to jtreg if wonted. The patch is for 8, but is valid also for 9, except the path to file. I will adapt it to 9 once you are ok with it (or you may on your own, depends on you) J. > On 09.11.15 15:45, Alexander Scherbatiy wrote: >> On 11/7/2015 11:38 AM, Jiri Vanek wrote: >>> Hello! >>> >>> Looking to imageIO.java (if this is bad thread, please redirect me!) >> >> 2d-dev alias should be also the right place to ask image related >> questions in AWT. >> >> Thanks, >> Alexandr. >> >>> when reading images >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 >>> >>> >>> and ending at: >>> >>> // Perform mark/reset as a defensive measure >>> // even though plug-ins are supposed to take >>> // care of it. >>> boolean canDecode = false; >>> if (stream != null) { >>> stream.mark(); >>> } >>> canDecode = spi.canDecodeInput(input); >>> if (stream != null) { >>> stream.reset(); >>> } >>> return canDecode; >>> >>> I'm wondering, why stream.reset(); is not in finaly block: >>> >>> // Perform mark/reset as a defensive measure >>> // even though plug-ins are supposed to take >>> // care of it. >>> boolean canDecode = false; >>> if (stream != null) { >>> stream.mark(); >>> } >>> try{ >>> canDecode = spi.canDecodeInput(input); >>> } finally { >>> if (stream != null) { >>> stream.reset(); >>> } >>> } >>> return canDecode; >>> >>> >>> Eg png and bmp decoders can are throwing IIOException when header is >>> corrutped. That pretty definitely sure killer of stream mark stacks. >>> You yourselves write : //Perform mark/reset as a defensive measure >>> even though plug-ins are supposed to take care of it. >>> So if densive, then try/finaly please. >>> >>> I did not check if this changed in 9 but if not....Please. This is >>> makig work on custom image plugins, for image formats which just wraps >>> another bmp/png and are expecting corrupted headers preatty hards. >>> >>> >>> J. >> > > From jayathirth.d.v at oracle.com Thu Nov 19 09:49:08 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Thu, 19 Nov 2015 01:49:08 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-8074967: JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata Message-ID: Hi Phil/Prasanta, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-8074967 Webrev : http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.00/ Bug : JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata Root cause : In JPEG image if there is no JFIF or EXIF header. We are not checking component ID's to determine color space properly. Third channel component ID (3) is matching the length of componentSpecs length and we are not setting colorspace as YCbCr. It is set to RGB which is wrong. Solution : We should check for id greater than componentSpecs length and not greater than equal. But adding a tighter check to match individual component ID is better. So made changes to match individual component ID with 1, 2 & 3 to set color space as YCbCr. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Thu Nov 19 14:16:45 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 19 Nov 2015 17:16:45 +0300 Subject: [OpenJDK 2D-Dev] [9]: RFR JDK-8023213 [macosx] closed/java/awt/FontClass/NaNTransform.java fails on MacOS X 10.9 In-Reply-To: <564AC541.6080403@oracle.com> References: <56139AA1.2070705@oracle.com> <561CEFCB.2090305@oracle.com> <56327478.1060105@oracle.com> <563721AB.90407@oracle.com> <563A93B8.1010202@oracle.com> <563C5B77.2060607@oracle.com> <564A5062.5070301@oracle.com> <564AC541.6080403@oracle.com> Message-ID: <564DD9CD.8050906@oracle.com> I still think that possibly it will be better to block such transforms on the upper level, somewhere in the java probably in CStrike.java. On 17.11.15 9:12, prasanta sadhukhan wrote: > Hi Phil, > > I have updated webrev to explicitly set glyph image width/height to be 0 > in case of NaN transform. Could you please review it? > http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.02/ > > Regards > Prasanta > On 11/17/2015 3:23 AM, Phil Race wrote: >> Would it not be better to be explicit in this so as not to leave it to >> chance ? >> >> -phil. >> >> On 11/05/2015 11:49 PM, prasanta sadhukhan wrote: >>> Hi Phil, >>> >>> On 11/5/2015 4:54 AM, Philip Race wrote: >>>> This does not look right to me. Who knows what data is on the canvas ? >>>> it is not clear that it is 'blank'. It could have data from a >>>> previous glyph .. I am not >>>> sure how you know for sure. I can see that canvas is re-used. There >>>> is reference >>>> to a "global shared canvas". >>>> And the actual function you invoke is one of two : one for grey and >>>> one for lcd and >>>> looking at the grey one CGGI_CopyImageFromCanvasToAlphaInfo) >>>> it utilises info->width and info->height which can't be NaN because >>>> they >>>> are uint16 but I don't know if they are valid .. and is the "image" >>>> field >>>> allocated to be 0 length ? >>> info->width & height is coming out to be 0 in case of NaN transform >>> therefore "image" field will be of 0 length so "empty" glyph will be >>> copied when we copy the "glyph image" from canvas (no matter what is >>> there in canvas) to info->image via this code >>> http://hg.openjdk.java.net/jdk9/client/jdk/file/298d3fe64572/src/java.desktop/macosx/native/libawt_lwawt/font/CGGlyphImages.m#l294 >>> >>> >>> >>> size_t destRow = y * destRowWidth; >>> size_t srcRow = y * srcRowWidth; >>> size_t x; >>> for (x = 0; x < destRowWidth; x++) { >>> UInt32 p = src[srcRow + x]; >>> dest[destRow + x] = CGGI_ConvertBWPixelToByteGray(p); >>> >>> where destRowWidth = destRow = info->width will be 0 so dest = >>> info->image will be of 0 length >>> >>> Regards >>> Prasanta >>>> Could you step through how this is all guaranteed >>>> to be safe/correct ? >>>> >>>> -phil. >>>> >>>> On 11/2/15, 12:41 AM, prasanta sadhukhan wrote: >>>>> Hi Phil, >>>>> >>>>> I have modified as per your review to populate GlyphInfo with >>>>> "empty" glyph >>>>> and also moved your existing test to "open" >>>>> I also added a Infinite Transform test along with your NaN >>>>> transform just incase (in fact Sergey informally asked me to check) >>>>> >>>>> http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.01/ >>>>> >>>>> Regards >>>>> Prasanta >>>>> On 10/30/2015 1:03 AM, Phil Race wrote: >>>>>> Should this new check go before this : >>>>>> >>>>>> CGGI_ClearCanvas(canvas, info); >>>>>> >>>>>> since it is using info which is where you get NaN from. >>>>>> >>>>>> >>>>>> And should we then populate the returned canvas and info to >>>>>> ensure that we return an "empty" glyph rather than garbage values ? >>>>>> It is not clear to me that this is occurring. >>>>>> >>>>>> Why does the bug report not contain the evaluation below ? >>>>>> Also why is there a new test ? I would expect SQE would >>>>>> want to run the existing test to verify this fix. >>>>>> Should we not just open the existing test ? >>>>>> >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 10/13/2015 04:49 AM, prasanta sadhukhan wrote: >>>>>>> Gentle reminder for review >>>>>>> >>>>>>> Regards >>>>>>> Prasanta >>>>>>> On 10/6/2015 3:25 PM, prasanta sadhukhan wrote: >>>>>>>> Hello All, >>>>>>>> >>>>>>>> Please review a fix for jdk9 >>>>>>>> >>>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8023213 >>>>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8023213/webrev.00/ >>>>>>>> >>>>>>>> drawString takes long time in mac native call >>>>>>>> CGContextShowGlyphsAtPoint() if NaN transform is used which >>>>>>>> translated to x & y being NaN. >>>>>>>> Fix is to prevent calling mac api for such invalid usage. >>>>>>>> >>>>>>>> Regards >>>>>>>> Prasanta >>>>>>> >>>>>> >>>>> >>> >> > -- Best regards, Sergey. From steven.loomis at oracle.com Thu Nov 19 20:51:47 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Thu, 19 Nov 2015 12:51:47 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564BC0CD.7080207@oracle.com> References: <564BC0CD.7080207@oracle.com> Message-ID: <564E3663.3080902@oracle.com> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ directory) and it looks good so far. -s On 11/17/2015 4:05 PM, Philip Race wrote: > Webrev : http://cr.openjdk.java.net/~prr/8143177/ > Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 > > This webrev contains the changes accumulated in the harfbuzz project > forest > that migrate JDK from using ICU for opentype font layout to harfbuzz > for the same. > > The change does not introduce API. It is mostly adding the harfbuzz > library. > The ICU library remains there but is no longer the default. > Eventually (not necessarily in 9) it may be removed once we are > comfortable > with harfbuzz. > You may select ICU by using -Dsun.font.layoutengine=icu > > You may see which layout engine is in use by using > -Dsun.font.layoutengine.verbose=true > it will print either "Using harfbuzz", or "Using ICU". > > The change has no impact on typical Latin script rendering but is a > big advance > for complex scripts and also applies if you select kerning or > ligatures for Latin. > However the latter is only detectable if the font implements support > for these. > By "big advance" I mean that ICU has not been updated to recognise > recent opentype features. > So harfbuzz should fix a number of things but unexpected changes that > look wrong > should be reported so we can investigate. > > To use harfbuzz we invoke its shaper and we provide a way to get jdk > font information. > This means that we do not need a different layer depending on whether > freetype or t2k > is used. It also enables some caching in the JDK font layer. > > On macosx harfbuzz does not natively read the AAT tables but will > invoke CoreText. > This does mean that an AAT font installed on Linux would not be > processed but > this is not a significant issue since AAT fonts are not found other > than on macosx. > > The majority of the files in the webrev are harfbuzz itself, changed > only to comply > with JDK whitespace rules. Reviewers should probably concentrate on > all of the rest. > I've listed it so that all those files are at the beginning and you > can ignore all those > that follow that are in the "harfbuzz" directory. > > The harfbuzz version used here is 1.0.6 which is the latest source > release (at the time of writing). > We expect to update this to keep reasonably current. > > I would like to push this in on Friday, but at the very latest Monday > because of the > upcoming Feature Complete date so there are a couple of days to make > small > tweaks for serious problems but there will be plenty of time after > integration to fix > remaining problems. > > -phil. > From brian.burkhalter at oracle.com Thu Nov 19 21:48:09 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 19 Nov 2015 13:48:09 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 Message-ID: Please review at your convenience: Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ This review request pertains to the changes required to integrate Java Image I/O support for TIFF into JDK 9. The two branches of the webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK repository and the top level JDK forest repository, respectively. The latter only adds the new package javax.imageio.plugins.tiff to the list of packages which form the Java API Specification. The 8143342.00-jdk branch contains the actual source code and HTML changes. There are three subsets of this branch: 1) changes to existing files, 2) new files in the public API, and 3) new files in the non-public implementation. The portions of the changes to existing files which affect visible API or the behavior of existing API are to add the TIFF reader and writer plugin SPIs to the IIORegistry and to link the TIFF Metadata Format Specification and Usage Notes document from the javax.imageio.metadata package summary. The new files in the public API are the classes in the javax.imageio.plugins.tiff package, the package summary, and the aforementioned metadata and usage document tiff_metadata.html. The new API is principally concerned with a simplified approach to handling TIFF image metadata. If metadata are not of concern then there should be no need to use the classes in this package. The new files in the non-public API are the classes in the com.sun.imageio.plugins.tiff package. These classes handle the reading and writing of TIFF image data and metadata. Thanks, Brian From philip.race at oracle.com Fri Nov 20 03:13:19 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Nov 2015 19:13:19 -0800 Subject: [OpenJDK 2D-Dev] Duplicated (or better multiplicated) image-decoder resolvers in openjdk In-Reply-To: <564CB148.90300@oracle.com> References: <56336CE6.2010106@redhat.com> <564CB148.90300@oracle.com> Message-ID: <564E8FCF.6060807@oracle.com> Yes this is really 2d rather than AWT. Image I/O dates from 1.0 whereas Toolkit.createImage(..) dates from 1.0 They share almost no implementation, what there is that is shared is the IJG JPEG library. It would be nice if TK.createImage just delegated to Image I/O. Some years ago we considered something like this and step #1 was to make sure about compatibility and performance and a fair amount of work was done but we did not have resources to follow up. At this time it could be a JDK10 goal for step #2 to investigate and decide whether it makes sense. There are still issues like when or if colour space conversion is done. I do not off-hand remember if there is any obstacle to icedtea's TK image support simply "understanding" .ico's since I do not recall any definitive list in the SE spec of what TK.createImage may (or may not) support. And you can create an image i/o plugin too but not as a standard plugin. -phil On 11/18/15, 9:11 AM, Sergey Bylokhov wrote: > Hi, Jiri. > This question also related to 2d area(cc) > > I think it is possible to use the PNGImageReader(spi) instead of > sun.awt.PNGImageDecoder, which will allow automatically handle the > nondefault image formats. But as far as I know there are no plan to do > it in jdk9. > > On 30.10.15 16:13, Jiri Vanek wrote: >> Hello! >> >> Recently I was doing ico imagereader-spi provider for icedtea-web >> (which is javaws (and plugin) implementation for openjdk) >> Yes, ico is stupid, but is in web standards so having its support is >> just natural. However, providing spi did not solved the problem i was >> bugged for. >> >> After small debugging why, I found that eg SunToolkit.createImage and >> relatives - which are quite heavily used, do not honour ImageIO SPIs and >> are going by its own way: >> >> >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/FileImageSource.java#l50 >> >> >> for file >> and >> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/InputStreamImageSource.java#l213 >> >> >> for stream >> >> Well maybe its legacy bourden, but it is reimplementing what image SPIs >> providers via (apis canDecodeInput[2]) do. Long story short - >> reimplementing wheel and duplicated (very duplicated) code. >> >> I wonted to ask, if there are any plans in jdk9 to fix this. If no, what >> can I do to make it happen. >> >> >> Thanx! >> J. >> >> >> [2] >> https://docs.oracle.com/javase/7/docs/api/javax/imageio/spi/ImageReaderSpi.html#canDecodeInput%28java.lang.Object%29 >> >> >> https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageReader.html > > From philip.race at oracle.com Fri Nov 20 03:41:19 2015 From: philip.race at oracle.com (Philip Race) Date: Thu, 19 Nov 2015 19:41:19 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: References: Message-ID: <564E965F.5030008@oracle.com> The changes to pre-existing files look good although it is not apparent to me why you deleted this in iio-plugin.properties SimpleRenderedImage0=The provided region doesn't intersect with the image bounds is it just not used ? The rest I barely "skimmed" but I give it a go. -phil. On 11/19/15, 1:48 PM, Brian Burkhalter wrote: > Please review at your convenience: > > Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 > Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ > > This review request pertains to the changes required to integrate Java Image I/O support for TIFF into JDK 9. The two branches of the webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK repository and the top level JDK forest repository, respectively. The latter only adds the new package javax.imageio.plugins.tiff to the list of packages which form the Java API Specification. > > The 8143342.00-jdk branch contains the actual source code and HTML changes. There are three subsets of this branch: 1) changes to existing files, 2) new files in the public API, and 3) new files in the non-public implementation. > > The portions of the changes to existing files which affect visible API or the behavior of existing API are to add the TIFF reader and writer plugin SPIs to the IIORegistry and to link the TIFF Metadata Format Specification and Usage Notes document from the javax.imageio.metadata package summary. > > The new files in the public API are the classes in the javax.imageio.plugins.tiff package, the package summary, and the aforementioned metadata and usage document tiff_metadata.html. The new API is principally concerned with a simplified approach to handling TIFF image metadata. If metadata are not of concern then there should be no need to use the classes in this package. > > The new files in the non-public API are the classes in the com.sun.imageio.plugins.tiff package. These classes handle the reading and writing of TIFF image data and metadata. > > Thanks, > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Nov 20 11:49:10 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 20 Nov 2015 14:49:10 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D Message-ID: <564F08B6.7010009@oracle.com> Hello, Could you review the fix: bug: https://bugs.openjdk.java.net/browse/JDK-8069348 webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 For some reasons Blit operation does not properly work in the SunGraphics2D.copyArea() method with scaled transform neither on Windows nor on Mac OS X. I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() does not properly handle Blit operation The current solution updates D3DSurfaceData.copyArea() to handle scaled graphics in the same way as it has been already done for the CGLSurfaceData (see JDK-8000629 [macosx] Blurry rendering with Java 7 on Retina display). May be there is a way to avoid the code duplication: put it to some SurfaceDataUtils class (it also requires adding parent copyArea() method to BufferedRenderPipe) or something else. I am not sure about the best option. Thanks, Alexandr. From james.graham at oracle.com Fri Nov 20 15:26:05 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 Nov 2015 07:26:05 -0800 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <564F08B6.7010009@oracle.com> References: <564F08B6.7010009@oracle.com> Message-ID: <564F3B8D.8080309@oracle.com> The fix looks fine, but I see the following issues with the test case: - For a test case that claims to test copyArea(), it never calls that method anywhere...? - There is no need to display a frame on the screen and use Robot to reproduce the problem, it can all be done by creating a VolatileImage and doing the copyArea on that, and then reading back from the VI to see if it happened correctly, can't it? ...jim On 11/20/15 3:49 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8069348 > webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 > > For some reasons Blit operation does not properly work in the > SunGraphics2D.copyArea() method > with scaled transform neither on Windows nor on Mac OS X. > I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() > does not properly handle Blit operation > > The current solution updates D3DSurfaceData.copyArea() to handle > scaled graphics in the same way > as it has been already done for the CGLSurfaceData (see JDK-8000629 > [macosx] Blurry rendering with Java 7 on Retina display). > > May be there is a way to avoid the code duplication: put it to some > SurfaceDataUtils class (it also > requires adding parent copyArea() method to BufferedRenderPipe) or > something else. I am not sure about the best option. > > > Thanks, > Alexandr. > From brian.burkhalter at oracle.com Fri Nov 20 15:35:06 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 20 Nov 2015 07:35:06 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: <564E965F.5030008@oracle.com> References: <564E965F.5030008@oracle.com> Message-ID: On Nov 19, 2015, at 7:41 PM, Philip Race wrote: > The changes to pre-existing files look good although it is not apparent > to me why you deleted this in iio-plugin.properties > SimpleRenderedImage0=The provided region doesn't intersect with the image bounds > is it just not used ? That is correct. The search find src/java.desktop/share/classes -name '*.java' -exec grep SimpleRenderedImage0 {} \; -print does not print anything. > The rest I barely "skimmed" but I give it a go. OK, thanks. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Fri Nov 20 15:38:52 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 20 Nov 2015 18:38:52 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <564F08B6.7010009@oracle.com> References: <564F08B6.7010009@oracle.com> Message-ID: <564F3E8C.3040400@oracle.com> On 20.11.15 14:49, Alexander Scherbatiy wrote: > > Hello, > > Could you review the fix: > bug: https://bugs.openjdk.java.net/browse/JDK-8069348 > webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 > > For some reasons Blit operation does not properly work in the > SunGraphics2D.copyArea() method > with scaled transform neither on Windows nor on Mac OS X. > I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() > does not properly handle Blit operation Interesting. > > The current solution updates D3DSurfaceData.copyArea() to handle > scaled graphics in the same way > as it has been already done for the CGLSurfaceData (see JDK-8000629 > [macosx] Blurry rendering with Java 7 on Retina display). Note that this fix does not help ogl on windows right? because on windows the usual ogl blit should be used since the fix for retina was osx specific. Or it works properly? > > May be there is a way to avoid the code duplication: put it to some > SurfaceDataUtils class (it also > requires adding parent copyArea() method to BufferedRenderPipe) or > something else. I am not sure about the best option. This is up to the 2d team, but I think yes, it will be better to move it somewhere because after the current fix the different pipelines will behave differently on different platforms for a different transformations =( > > > Thanks, > Alexandr. > -- Best regards, Sergey. From james.graham at oracle.com Fri Nov 20 15:59:28 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 Nov 2015 07:59:28 -0800 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <564F3E8C.3040400@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> Message-ID: <564F4360.3070609@oracle.com> In terms of consolidating the code... Since SD.copyArea is an internal API, we could simply specify that it takes pixel coordinates and assumes COPY semantics so it is up to SG2D to verify the transform and compState and perform appropriate coordinate transformations before asking the SD to do the dirty work. I'm not sure why we left so much veto power up to the SD class there... ...jim On 11/20/15 7:38 AM, Sergey Bylokhov wrote: > On 20.11.15 14:49, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the fix: >> bug: https://bugs.openjdk.java.net/browse/JDK-8069348 >> webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 >> >> For some reasons Blit operation does not properly work in the >> SunGraphics2D.copyArea() method >> with scaled transform neither on Windows nor on Mac OS X. >> I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() >> does not properly handle Blit operation > > Interesting. > >> >> The current solution updates D3DSurfaceData.copyArea() to handle >> scaled graphics in the same way >> as it has been already done for the CGLSurfaceData (see JDK-8000629 >> [macosx] Blurry rendering with Java 7 on Retina display). > > Note that this fix does not help ogl on windows right? because on > windows the usual ogl blit should be used since the fix for retina was > osx specific. Or it works properly? > >> >> May be there is a way to avoid the code duplication: put it to some >> SurfaceDataUtils class (it also >> requires adding parent copyArea() method to BufferedRenderPipe) or >> something else. I am not sure about the best option. > > This is up to the 2d team, but I think yes, it will be better to move it > somewhere because after the current fix the different pipelines will > behave differently on different platforms for a different > transformations =( > >> >> >> Thanks, >> Alexandr. >> > > From philip.race at oracle.com Fri Nov 20 23:09:59 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 20 Nov 2015 15:09:59 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564E3663.3080902@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> Message-ID: <564FA847.5040404@oracle.com> On 11/19/2015 12:51 PM, Steven Loomis wrote: > I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ > directory) and it looks good so far. Thanks. The harfbuzz code itself probably does not need careful reviewing as it is just the upstream harfbuzz. I have updated it to remove the gpl text from the hb src files but I haven't changed anything else :- http://cr.openjdk.java.net/~prr/8143177.1/ Any takers to be 2nd reviewer ? -phil. > > -s > > On 11/17/2015 4:05 PM, Philip Race wrote: >> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >> >> This webrev contains the changes accumulated in the harfbuzz project >> forest >> that migrate JDK from using ICU for opentype font layout to harfbuzz >> for the same. >> >> The change does not introduce API. It is mostly adding the harfbuzz >> library. >> The ICU library remains there but is no longer the default. >> Eventually (not necessarily in 9) it may be removed once we are >> comfortable >> with harfbuzz. >> You may select ICU by using -Dsun.font.layoutengine=icu >> >> You may see which layout engine is in use by using >> -Dsun.font.layoutengine.verbose=true >> it will print either "Using harfbuzz", or "Using ICU". >> >> The change has no impact on typical Latin script rendering but is a >> big advance >> for complex scripts and also applies if you select kerning or >> ligatures for Latin. >> However the latter is only detectable if the font implements support >> for these. >> By "big advance" I mean that ICU has not been updated to recognise >> recent opentype features. >> So harfbuzz should fix a number of things but unexpected changes that >> look wrong >> should be reported so we can investigate. >> >> To use harfbuzz we invoke its shaper and we provide a way to get jdk >> font information. >> This means that we do not need a different layer depending on whether >> freetype or t2k >> is used. It also enables some caching in the JDK font layer. >> >> On macosx harfbuzz does not natively read the AAT tables but will >> invoke CoreText. >> This does mean that an AAT font installed on Linux would not be >> processed but >> this is not a significant issue since AAT fonts are not found other >> than on macosx. >> >> The majority of the files in the webrev are harfbuzz itself, changed >> only to comply >> with JDK whitespace rules. Reviewers should probably concentrate on >> all of the rest. >> I've listed it so that all those files are at the beginning and you >> can ignore all those >> that follow that are in the "harfbuzz" directory. >> >> The harfbuzz version used here is 1.0.6 which is the latest source >> release (at the time of writing). >> We expect to update this to keep reasonably current. >> >> I would like to push this in on Friday, but at the very latest Monday >> because of the >> upcoming Feature Complete date so there are a couple of days to make >> small >> tweaks for serious problems but there will be plenty of time after >> integration to fix >> remaining problems. >> >> -phil. >> > From james.graham at oracle.com Sat Nov 21 00:38:05 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 20 Nov 2015 16:38:05 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration Message-ID: <564FBCED.4030501@oracle.com> Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 This webrev contains the changes accumulated in the Graphics-Rasterizer project forest that add the Marlin AA renderer to the JDK and make it the default AA RenderingEngine for Java2D. The webrev also includes a link to an HTML output of J2DAnalyzer showing the relative performance on a few basic rendering tests for Ductus, Marlin, and Pisces. This change does not introduce any new API, but it does introduce a new debugging property to see which RenderingEngine is in use. Java2D already supported selecting a RenderingEngine on the fly using: -Dsun.java2d.renderer= The default is now set to Marlin. You may now also see which RenderingEngine is in use by using (new with this patch): -Dsun.java2d.renderer.verbose=true The default rendering engine used to be Pisces for OpenJDK and Ductus for Oracle's products, but the new default will be the new Marlin renderer for all builds. Pisces is still built and included in OpenJDK builds and both Pisces and Ductus are still built and included in Oracle builds, but the user must select those RenderingEngine implementations on the command line to use them. The alternate engines may be deprecated and removed over time. Marlin already outperforms Pisces in every category by a wide margin (except for a few basic tests where it has roughly the same performance to within a margin of error, and roughly the same as Ductus as well). In addition, Marlin just recently reached a level of performance comparable to Ductus in single-threaded benchmarks. But, where Marlin shines is in multi-threaded performance where Ductus had nearly 0% scalability (and on some benchmarks would often take more than N times longer to render something with N threads) due to a required java-level synchronized access to the unprotected singleton native data structures. Marlin's scalability is very high - in the 90% range. In MT tests with N threads (N < #cores) Marlin can be about N times faster or more than Ductus which is a huge win for server-side use. In terms of accuracy, a quick test of comparing the AA renderers output to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale and then use a series of N linear interpolation steps to cut the resolution back to normal size) using 8x8 oversampling shows that Marlin is, on average, about twice as accurate as Ductus, and close to 2.5 to 3 times more accurate than Pisces. Here is the text summary from analyzing the J2DBench results included in the webrev above. Note that Pisces is only 40-100% the performance of Ductus (at best it achieves parity), whereas Marlin is 92-220% the performance as Ductus (from near parity to over twice as fast): Summary: Ductus Renderer on Mac: Number of tests: 14 Overall average: 271435.684621936 Best spread: 0.25% variance Worst spread: 0.81% variance (Basis for results comparison) Marlin Renderer on Mac: Number of tests: 14 Overall average: 278609.9151360187 Best spread: 0.24% variance Worst spread: 0.94% variance Comparison to basis: Best result: 219.63% of basis Worst result: 91.71% of basis Number of wins: 5 Number of ties: 5 Number of losses: 4 Pisces Renderer on Mac: Number of tests: 14 Overall average: 264688.87069247436 Best spread: 0.12% variance Worst spread: 9.28% variance Comparison to basis: Best result: 101.71% of basis Worst result: 40.04% of basis Number of wins: 0 Number of ties: 6 Number of losses: 8 For multi-threaded performance, we are still modifying J2DBench to do MT testing, but meanwhile here are some sample results from a micro-mt-benchmark that I was using to measure Marlin's benefit over Ductus, all tests run on my quad-core retina MacBook Pro: RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc Results for 4 threads: Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op Stroking Big Circle took 20001.6ms for 12744 ops = 1.5694947735404898ms/op Filling Small Circle took 20000.0ms for 650166 ops = 0.030761436459304237ms/op Stroking Small Circle took 20000.2ms for 563230 ops = 0.03550988808657209ms/op Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = 3.1412907711997486ms/op Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = 4.958922349529003ms/op Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = 48.53754647457627ms/op Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = 120.74043964670658ms/op RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec Results for 4 threads: Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op Stroking Big Circle took 20000.3ms for 74332 ops = 0.2690665217672066ms/op Filling Small Circle took 20000.0ms for 3999239 ops = 0.0050009547403893585ms/op Stroking Small Circle took 20000.0ms for 1692821 ops = 0.011814607555081133ms/op Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = 0.6346507143582422ms/op Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = 0.9029244853737812ms/op Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = 13.599594945652175ms/op Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = 34.748233308492196ms/op RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc Results for 4 threads: Filling Big Circle took 20000.7ms for 52844 ops = 0.37848658839224886ms/op Stroking Big Circle took 20001.1ms for 39741 ops = 0.5032854199944641ms/op Filling Small Circle took 20000.0ms for 1628357 ops = 0.012282338621076336ms/op Stroking Small Circle took 20000.1ms for 809256 ops = 0.024714137085174535ms/op Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = 1.3557410718449234ms/op Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = 2.042433472582457ms/op Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = 17.572960124561405ms/op Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = 59.509273902077155ms/op ...jim From steven.loomis at oracle.com Sat Nov 21 02:08:46 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Fri, 20 Nov 2015 18:08:46 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564FA847.5040404@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> Message-ID: <564FD22E.1050908@oracle.com> By the way - this patch fixes https://bugs.openjdk.java.net/browse/JDK-8050404 for example. Syriac is supported in the JDK with this patch! >>> big advance for complex scripts and also applies if you select >>> kerning or ligatures for Latin. >>> However the latter is only detectable if the font implements support >>> for these. >>> By "big advance" I mean that ICU has not been updated to recognise >>> recent opentype features. >>> So harfbuzz should fix a number of things but unexpected changes >>> that look wrong >>> should be reported so we can investigate. >>> From steven.loomis at oracle.com Sat Nov 21 02:33:32 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Fri, 20 Nov 2015 18:33:32 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564FA847.5040404@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> Message-ID: <564FD7FC.4080405@oracle.com> The .1 looks good to me Also, https://bugs.openjdk.java.net/browse/JDK-8037574 (and many more I'm sure) are also fixed by this. -s On 11/20/2015 3:09 PM, Phil Race wrote: > > On 11/19/2015 12:51 PM, Steven Loomis wrote: >> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ >> directory) and it looks good so far. > > Thanks. The harfbuzz code itself probably does not need careful > reviewing as it is just > the upstream harfbuzz. I have updated it to remove the gpl text from > the hb src files but > I haven't changed anything else :- > http://cr.openjdk.java.net/~prr/8143177.1/ > > Any takers to be 2nd reviewer ? > > -phil. > >> >> -s >> >> On 11/17/2015 4:05 PM, Philip Race wrote: >>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>> >>> This webrev contains the changes accumulated in the harfbuzz project >>> forest >>> that migrate JDK from using ICU for opentype font layout to harfbuzz >>> for the same. >>> >>> The change does not introduce API. It is mostly adding the harfbuzz >>> library. >>> The ICU library remains there but is no longer the default. >>> Eventually (not necessarily in 9) it may be removed once we are >>> comfortable >>> with harfbuzz. >>> You may select ICU by using -Dsun.font.layoutengine=icu >>> >>> You may see which layout engine is in use by using >>> -Dsun.font.layoutengine.verbose=true >>> it will print either "Using harfbuzz", or "Using ICU". >>> >>> The change has no impact on typical Latin script rendering but is a >>> big advance >>> for complex scripts and also applies if you select kerning or >>> ligatures for Latin. >>> However the latter is only detectable if the font implements support >>> for these. >>> By "big advance" I mean that ICU has not been updated to recognise >>> recent opentype features. >>> So harfbuzz should fix a number of things but unexpected changes >>> that look wrong >>> should be reported so we can investigate. >>> >>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>> font information. >>> This means that we do not need a different layer depending on >>> whether freetype or t2k >>> is used. It also enables some caching in the JDK font layer. >>> >>> On macosx harfbuzz does not natively read the AAT tables but will >>> invoke CoreText. >>> This does mean that an AAT font installed on Linux would not be >>> processed but >>> this is not a significant issue since AAT fonts are not found other >>> than on macosx. >>> >>> The majority of the files in the webrev are harfbuzz itself, changed >>> only to comply >>> with JDK whitespace rules. Reviewers should probably concentrate on >>> all of the rest. >>> I've listed it so that all those files are at the beginning and you >>> can ignore all those >>> that follow that are in the "harfbuzz" directory. >>> >>> The harfbuzz version used here is 1.0.6 which is the latest source >>> release (at the time of writing). >>> We expect to update this to keep reasonably current. >>> >>> I would like to push this in on Friday, but at the very latest >>> Monday because of the >>> upcoming Feature Complete date so there are a couple of days to make >>> small >>> tweaks for serious problems but there will be plenty of time after >>> integration to fix >>> remaining problems. >>> >>> -phil. >>> >> > From vadim.pakhnushev at oracle.com Sat Nov 21 10:41:15 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sat, 21 Nov 2015 13:41:15 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564FA847.5040404@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> Message-ID: <56504A4B.6000709@oracle.com> Phil, In the HBShaper.c in the init_JNI_IDs function I think CHECK_NULL is missing for the gvdIndicesFID. I guess it's just a copy from SunLayoutEngine.cpp but still. Calling init_JNI_IDs each time seems unneeded (not very harmful though), could it be somehow merged with the Java_sun_font_SunLayoutEngine_initGVIDs? What's the point of this super optimized euclidianDistance if it's called only 2 times while creating a layout? pScaler is not used anywhere it seems, can it be removed altogether? typo in the hb-jdk-font.cc:124 * which *be could* based on some on-the fly glyph analysis. Thanks, Vadim On 21.11.2015 2:09, Phil Race wrote: > > On 11/19/2015 12:51 PM, Steven Loomis wrote: >> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ >> directory) and it looks good so far. > > Thanks. The harfbuzz code itself probably does not need careful > reviewing as it is just > the upstream harfbuzz. I have updated it to remove the gpl text from > the hb src files but > I haven't changed anything else :- > http://cr.openjdk.java.net/~prr/8143177.1/ > > Any takers to be 2nd reviewer ? > > -phil. > >> >> -s >> >> On 11/17/2015 4:05 PM, Philip Race wrote: >>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>> >>> This webrev contains the changes accumulated in the harfbuzz project >>> forest >>> that migrate JDK from using ICU for opentype font layout to harfbuzz >>> for the same. >>> >>> The change does not introduce API. It is mostly adding the harfbuzz >>> library. >>> The ICU library remains there but is no longer the default. >>> Eventually (not necessarily in 9) it may be removed once we are >>> comfortable >>> with harfbuzz. >>> You may select ICU by using -Dsun.font.layoutengine=icu >>> >>> You may see which layout engine is in use by using >>> -Dsun.font.layoutengine.verbose=true >>> it will print either "Using harfbuzz", or "Using ICU". >>> >>> The change has no impact on typical Latin script rendering but is a >>> big advance >>> for complex scripts and also applies if you select kerning or >>> ligatures for Latin. >>> However the latter is only detectable if the font implements support >>> for these. >>> By "big advance" I mean that ICU has not been updated to recognise >>> recent opentype features. >>> So harfbuzz should fix a number of things but unexpected changes >>> that look wrong >>> should be reported so we can investigate. >>> >>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>> font information. >>> This means that we do not need a different layer depending on >>> whether freetype or t2k >>> is used. It also enables some caching in the JDK font layer. >>> >>> On macosx harfbuzz does not natively read the AAT tables but will >>> invoke CoreText. >>> This does mean that an AAT font installed on Linux would not be >>> processed but >>> this is not a significant issue since AAT fonts are not found other >>> than on macosx. >>> >>> The majority of the files in the webrev are harfbuzz itself, changed >>> only to comply >>> with JDK whitespace rules. Reviewers should probably concentrate on >>> all of the rest. >>> I've listed it so that all those files are at the beginning and you >>> can ignore all those >>> that follow that are in the "harfbuzz" directory. >>> >>> The harfbuzz version used here is 1.0.6 which is the latest source >>> release (at the time of writing). >>> We expect to update this to keep reasonably current. >>> >>> I would like to push this in on Friday, but at the very latest >>> Monday because of the >>> upcoming Feature Complete date so there are a couple of days to make >>> small >>> tweaks for serious problems but there will be plenty of time after >>> integration to fix >>> remaining problems. >>> >>> -phil. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Sat Nov 21 23:07:57 2015 From: philip.race at oracle.com (Philip Race) Date: Sat, 21 Nov 2015 15:07:57 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <56504A4B.6000709@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> <56504A4B.6000709@oracle.com> Message-ID: <5650F94D.8080708@oracle.com> http://cr.openjdk.java.net/~prr/8143177.2 is uploaded. See comments below. On 11/21/15, 2:41 AM, Vadim Pakhnushev wrote: > Phil, > > In the HBShaper.c in the init_JNI_IDs function I think CHECK_NULL is > missing for the gvdIndicesFID. > I guess it's just a copy from SunLayoutEngine.cpp but still. Actually this points out that I only return from the init function and don't return from the calling function. I will restructure this a bit so that we return a success value and the caller checks it. > Calling init_JNI_IDs each time seems unneeded (not very harmful > though), could it be somehow merged with the > Java_sun_font_SunLayoutEngine_initGVIDs? They are static and I have added a static flag that indicates they have all been initialised. If it fails then we will not proceed. In the normal case overhead should be down to near zero. > What's the point of this super optimized euclidianDistance if it's > called only 2 times while creating a layout? I just copied this from ICU code so we are doing the same thing. > pScaler is not used anywhere it seems, can it be removed altogether? It was used when I was directly testing freetype (using harfbuzz's hb-ft.cc) That was where I started out but I moved on to a different approach. It is left it there in case I wanted to test ft to isolate any bugs. > > typo in the hb-jdk-font.cc:124 * which *be could* based on some > on-the fly glyph analysis. ok I had to make one additional change. The hb call to create a coretext font was being handed the pt size in device pixels as used elsewhere but in the coretext path we must pass the user pt size so I had to pass that down and in .. it does not affect anything except the coretext path for AAT fonts on OS X. I spotted this when testing with a transform in that code path. -phil. > > Thanks, > Vadim > > On 21.11.2015 2:09, Phil Race wrote: >> >> On 11/19/2015 12:51 PM, Steven Loomis wrote: >>> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ >>> directory) and it looks good so far. >> >> Thanks. The harfbuzz code itself probably does not need careful >> reviewing as it is just >> the upstream harfbuzz. I have updated it to remove the gpl text from >> the hb src files but >> I haven't changed anything else :- >> http://cr.openjdk.java.net/~prr/8143177.1/ >> >> Any takers to be 2nd reviewer ? >> >> -phil. >> >>> >>> -s >>> >>> On 11/17/2015 4:05 PM, Philip Race wrote: >>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>> >>>> This webrev contains the changes accumulated in the harfbuzz >>>> project forest >>>> that migrate JDK from using ICU for opentype font layout to >>>> harfbuzz for the same. >>>> >>>> The change does not introduce API. It is mostly adding the harfbuzz >>>> library. >>>> The ICU library remains there but is no longer the default. >>>> Eventually (not necessarily in 9) it may be removed once we are >>>> comfortable >>>> with harfbuzz. >>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>> >>>> You may see which layout engine is in use by using >>>> -Dsun.font.layoutengine.verbose=true >>>> it will print either "Using harfbuzz", or "Using ICU". >>>> >>>> The change has no impact on typical Latin script rendering but is a >>>> big advance >>>> for complex scripts and also applies if you select kerning or >>>> ligatures for Latin. >>>> However the latter is only detectable if the font implements >>>> support for these. >>>> By "big advance" I mean that ICU has not been updated to recognise >>>> recent opentype features. >>>> So harfbuzz should fix a number of things but unexpected changes >>>> that look wrong >>>> should be reported so we can investigate. >>>> >>>> To use harfbuzz we invoke its shaper and we provide a way to get >>>> jdk font information. >>>> This means that we do not need a different layer depending on >>>> whether freetype or t2k >>>> is used. It also enables some caching in the JDK font layer. >>>> >>>> On macosx harfbuzz does not natively read the AAT tables but will >>>> invoke CoreText. >>>> This does mean that an AAT font installed on Linux would not be >>>> processed but >>>> this is not a significant issue since AAT fonts are not found other >>>> than on macosx. >>>> >>>> The majority of the files in the webrev are harfbuzz itself, >>>> changed only to comply >>>> with JDK whitespace rules. Reviewers should probably concentrate on >>>> all of the rest. >>>> I've listed it so that all those files are at the beginning and you >>>> can ignore all those >>>> that follow that are in the "harfbuzz" directory. >>>> >>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>> release (at the time of writing). >>>> We expect to update this to keep reasonably current. >>>> >>>> I would like to push this in on Friday, but at the very latest >>>> Monday because of the >>>> upcoming Feature Complete date so there are a couple of days to >>>> make small >>>> tweaks for serious problems but there will be plenty of time after >>>> integration to fix >>>> remaining problems. >>>> >>>> -phil. >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.loomis at oracle.com Sun Nov 22 01:19:50 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Sat, 21 Nov 2015 17:19:50 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <5650F94D.8080708@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> <56504A4B.6000709@oracle.com> <5650F94D.8080708@oracle.com> Message-ID: <56511836.8020209@oracle.com> .2 looks good to me. -s On 11/21/2015 3:07 PM, Philip Race wrote: > http://cr.openjdk.java.net/~prr/8143177.2 > > is uploaded. See comments below. > > On 11/21/15, 2:41 AM, Vadim Pakhnushev wrote: >> Phil, >> >> In the HBShaper.c in the init_JNI_IDs function I think CHECK_NULL is >> missing for the gvdIndicesFID. >> I guess it's just a copy from SunLayoutEngine.cpp but still. > > Actually this points out that I only return from the init function > and don't return from the calling function. I will restructure this a > bit so that we > return a success value and the caller checks it. > >> Calling init_JNI_IDs each time seems unneeded (not very harmful >> though), could it be somehow merged with the >> Java_sun_font_SunLayoutEngine_initGVIDs? > > They are static and I have added a static flag that indicates they > have all been initialised. > If it fails then we will not proceed. In the normal case overhead > should be down to > near zero. > >> What's the point of this super optimized euclidianDistance if it's >> called only 2 times while creating a layout? > > I just copied this from ICU code so we are doing the same thing. > >> pScaler is not used anywhere it seems, can it be removed altogether? > It was used when I was directly testing freetype (using harfbuzz's > hb-ft.cc) > That was where I started out but I moved on to a different approach. > It is left it there in case I wanted to test ft to isolate any bugs. > >> >> typo in the hb-jdk-font.cc:124 * which *be could* based on some >> on-the fly glyph analysis. > > ok > > I had to make one additional change. The hb call to create a coretext font > was being handed the pt size in device pixels as used elsewhere but in > the coretext path we must pass the user pt size so I had to pass that > down and in .. it does not affect anything except the coretext path for > AAT fonts on OS X. I spotted this when testing with a transform in > that code path. > > -phil. >> >> Thanks, >> Vadim >> >> On 21.11.2015 2:09, Phil Race wrote: >>> >>> On 11/19/2015 12:51 PM, Steven Loomis wrote: >>>> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ >>>> directory) and it looks good so far. >>> >>> Thanks. The harfbuzz code itself probably does not need careful >>> reviewing as it is just >>> the upstream harfbuzz. I have updated it to remove the gpl text from >>> the hb src files but >>> I haven't changed anything else :- >>> http://cr.openjdk.java.net/~prr/8143177.1/ >>> >>> Any takers to be 2nd reviewer ? >>> >>> -phil. >>> >>>> >>>> -s >>>> >>>> On 11/17/2015 4:05 PM, Philip Race wrote: >>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>>> >>>>> This webrev contains the changes accumulated in the harfbuzz >>>>> project forest >>>>> that migrate JDK from using ICU for opentype font layout to >>>>> harfbuzz for the same. >>>>> >>>>> The change does not introduce API. It is mostly adding the >>>>> harfbuzz library. >>>>> The ICU library remains there but is no longer the default. >>>>> Eventually (not necessarily in 9) it may be removed once we are >>>>> comfortable >>>>> with harfbuzz. >>>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>>> >>>>> You may see which layout engine is in use by using >>>>> -Dsun.font.layoutengine.verbose=true >>>>> it will print either "Using harfbuzz", or "Using ICU". >>>>> >>>>> The change has no impact on typical Latin script rendering but is >>>>> a big advance >>>>> for complex scripts and also applies if you select kerning or >>>>> ligatures for Latin. >>>>> However the latter is only detectable if the font implements >>>>> support for these. >>>>> By "big advance" I mean that ICU has not been updated to recognise >>>>> recent opentype features. >>>>> So harfbuzz should fix a number of things but unexpected changes >>>>> that look wrong >>>>> should be reported so we can investigate. >>>>> >>>>> To use harfbuzz we invoke its shaper and we provide a way to get >>>>> jdk font information. >>>>> This means that we do not need a different layer depending on >>>>> whether freetype or t2k >>>>> is used. It also enables some caching in the JDK font layer. >>>>> >>>>> On macosx harfbuzz does not natively read the AAT tables but will >>>>> invoke CoreText. >>>>> This does mean that an AAT font installed on Linux would not be >>>>> processed but >>>>> this is not a significant issue since AAT fonts are not found >>>>> other than on macosx. >>>>> >>>>> The majority of the files in the webrev are harfbuzz itself, >>>>> changed only to comply >>>>> with JDK whitespace rules. Reviewers should probably concentrate >>>>> on all of the rest. >>>>> I've listed it so that all those files are at the beginning and >>>>> you can ignore all those >>>>> that follow that are in the "harfbuzz" directory. >>>>> >>>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>>> release (at the time of writing). >>>>> We expect to update this to keep reasonably current. >>>>> >>>>> I would like to push this in on Friday, but at the very latest >>>>> Monday because of the >>>>> upcoming Feature Complete date so there are a couple of days to >>>>> make small >>>>> tweaks for serious problems but there will be plenty of time after >>>>> integration to fix >>>>> remaining problems. >>>>> >>>>> -phil. >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vadim.pakhnushev at oracle.com Sun Nov 22 12:08:32 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Sun, 22 Nov 2015 15:08:32 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <5650F94D.8080708@oracle.com> References: <564BC0CD.7080207@oracle.com> <564E3663.3080902@oracle.com> <564FA847.5040404@oracle.com> <56504A4B.6000709@oracle.com> <5650F94D.8080708@oracle.com> Message-ID: <5651B040.8030200@oracle.com> Looks good to me. Vadim On 22.11.2015 2:07, Philip Race wrote: > http://cr.openjdk.java.net/~prr/8143177.2 > > is uploaded. See comments below. > > On 11/21/15, 2:41 AM, Vadim Pakhnushev wrote: >> Phil, >> >> In the HBShaper.c in the init_JNI_IDs function I think CHECK_NULL is >> missing for the gvdIndicesFID. >> I guess it's just a copy from SunLayoutEngine.cpp but still. > > Actually this points out that I only return from the init function > and don't return from the calling function. I will restructure this a > bit so that we > return a success value and the caller checks it. > >> Calling init_JNI_IDs each time seems unneeded (not very harmful >> though), could it be somehow merged with the >> Java_sun_font_SunLayoutEngine_initGVIDs? > > They are static and I have added a static flag that indicates they > have all been initialised. > If it fails then we will not proceed. In the normal case overhead > should be down to > near zero. > >> What's the point of this super optimized euclidianDistance if it's >> called only 2 times while creating a layout? > > I just copied this from ICU code so we are doing the same thing. > >> pScaler is not used anywhere it seems, can it be removed altogether? > It was used when I was directly testing freetype (using harfbuzz's > hb-ft.cc) > That was where I started out but I moved on to a different approach. > It is left it there in case I wanted to test ft to isolate any bugs. > >> >> typo in the hb-jdk-font.cc:124 * which *be could* based on some >> on-the fly glyph analysis. > > ok > > I had to make one additional change. The hb call to create a coretext font > was being handed the pt size in device pixels as used elsewhere but in > the coretext path we must pass the user pt size so I had to pass that > down and in .. it does not affect anything except the coretext path for > AAT fonts on OS X. I spotted this when testing with a transform in > that code path. > > -phil. >> >> Thanks, >> Vadim >> >> On 21.11.2015 2:09, Phil Race wrote: >>> >>> On 11/19/2015 12:51 PM, Steven Loomis wrote: >>>> I have reviewed the non-harfbuzz portion (outside of the /harfbuzz/ >>>> directory) and it looks good so far. >>> >>> Thanks. The harfbuzz code itself probably does not need careful >>> reviewing as it is just >>> the upstream harfbuzz. I have updated it to remove the gpl text from >>> the hb src files but >>> I haven't changed anything else :- >>> http://cr.openjdk.java.net/~prr/8143177.1/ >>> >>> Any takers to be 2nd reviewer ? >>> >>> -phil. >>> >>>> >>>> -s >>>> >>>> On 11/17/2015 4:05 PM, Philip Race wrote: >>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>>> >>>>> This webrev contains the changes accumulated in the harfbuzz >>>>> project forest >>>>> that migrate JDK from using ICU for opentype font layout to >>>>> harfbuzz for the same. >>>>> >>>>> The change does not introduce API. It is mostly adding the >>>>> harfbuzz library. >>>>> The ICU library remains there but is no longer the default. >>>>> Eventually (not necessarily in 9) it may be removed once we are >>>>> comfortable >>>>> with harfbuzz. >>>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>>> >>>>> You may see which layout engine is in use by using >>>>> -Dsun.font.layoutengine.verbose=true >>>>> it will print either "Using harfbuzz", or "Using ICU". >>>>> >>>>> The change has no impact on typical Latin script rendering but is >>>>> a big advance >>>>> for complex scripts and also applies if you select kerning or >>>>> ligatures for Latin. >>>>> However the latter is only detectable if the font implements >>>>> support for these. >>>>> By "big advance" I mean that ICU has not been updated to recognise >>>>> recent opentype features. >>>>> So harfbuzz should fix a number of things but unexpected changes >>>>> that look wrong >>>>> should be reported so we can investigate. >>>>> >>>>> To use harfbuzz we invoke its shaper and we provide a way to get >>>>> jdk font information. >>>>> This means that we do not need a different layer depending on >>>>> whether freetype or t2k >>>>> is used. It also enables some caching in the JDK font layer. >>>>> >>>>> On macosx harfbuzz does not natively read the AAT tables but will >>>>> invoke CoreText. >>>>> This does mean that an AAT font installed on Linux would not be >>>>> processed but >>>>> this is not a significant issue since AAT fonts are not found >>>>> other than on macosx. >>>>> >>>>> The majority of the files in the webrev are harfbuzz itself, >>>>> changed only to comply >>>>> with JDK whitespace rules. Reviewers should probably concentrate >>>>> on all of the rest. >>>>> I've listed it so that all those files are at the beginning and >>>>> you can ignore all those >>>>> that follow that are in the "harfbuzz" directory. >>>>> >>>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>>> release (at the time of writing). >>>>> We expect to update this to keep reasonably current. >>>>> >>>>> I would like to push this in on Friday, but at the very latest >>>>> Monday because of the >>>>> upcoming Feature Complete date so there are a couple of days to >>>>> make small >>>>> tweaks for serious problems but there will be plenty of time after >>>>> integration to fix >>>>> remaining problems. >>>>> >>>>> -phil. >>>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Sun Nov 22 12:33:41 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Sun, 22 Nov 2015 15:33:41 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <564C948F.6010400@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> Message-ID: <5651B625.7050105@oracle.com> On 18.11.15 18:09, Sergey Bylokhov wrote: > Hi, Phil. > Not an expert here, just a few notes: > - Copyright is missing: hb-jdk-font.cc, hb-jdk.h > - HBShaper.c: Do we need a code at 268? probably we can add some todo > or remove it? same comments about 8143177.2, or it is intended? > > On 18.11.15 3:05, Philip Race wrote: >> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >> >> This webrev contains the changes accumulated in the harfbuzz project >> forest >> that migrate JDK from using ICU for opentype font layout to harfbuzz for >> the same. >> >> The change does not introduce API. It is mostly adding the harfbuzz >> library. >> The ICU library remains there but is no longer the default. >> Eventually (not necessarily in 9) it may be removed once we are >> comfortable >> with harfbuzz. >> You may select ICU by using -Dsun.font.layoutengine=icu >> >> You may see which layout engine is in use by using >> -Dsun.font.layoutengine.verbose=true >> it will print either "Using harfbuzz", or "Using ICU". >> >> The change has no impact on typical Latin script rendering but is a big >> advance >> for complex scripts and also applies if you select kerning or ligatures >> for Latin. >> However the latter is only detectable if the font implements support for >> these. >> By "big advance" I mean that ICU has not been updated to recognise >> recent opentype features. >> So harfbuzz should fix a number of things but unexpected changes that >> look wrong >> should be reported so we can investigate. >> >> To use harfbuzz we invoke its shaper and we provide a way to get jdk >> font information. >> This means that we do not need a different layer depending on whether >> freetype or t2k >> is used. It also enables some caching in the JDK font layer. >> >> On macosx harfbuzz does not natively read the AAT tables but will invoke >> CoreText. >> This does mean that an AAT font installed on Linux would not be >> processed but >> this is not a significant issue since AAT fonts are not found other than >> on macosx. >> >> The majority of the files in the webrev are harfbuzz itself, changed >> only to comply >> with JDK whitespace rules. Reviewers should probably concentrate on all >> of the rest. >> I've listed it so that all those files are at the beginning and you can >> ignore all those >> that follow that are in the "harfbuzz" directory. >> >> The harfbuzz version used here is 1.0.6 which is the latest source >> release (at the time of writing). >> We expect to update this to keep reasonably current. >> >> I would like to push this in on Friday, but at the very latest Monday >> because of the >> upcoming Feature Complete date so there are a couple of days to make >> small >> tweaks for serious problems but there will be plenty of time after >> integration to fix >> remaining problems. >> >> -phil. >> > > -- Best regards, Sergey. From philip.race at oracle.com Sun Nov 22 16:58:21 2015 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 Nov 2015 08:58:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <5651B625.7050105@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> <5651B625.7050105@oracle.com> Message-ID: <5651F42D.3090403@oracle.com> On 11/22/15, 4:33 AM, Sergey Bylokhov wrote: > On 18.11.15 18:09, Sergey Bylokhov wrote: >> Hi, Phil. >> Not an expert here, just a few notes: >> - Copyright is missing: hb-jdk-font.cc, hb-jdk.h hmm. how did I miss that ? Fixed. >> - HBShaper.c: Do we need a code at 268? probably we can add some todo >> or remove it? I deleted the commented out code. Uploaded http://cr.openjdk.java.net/~prr/8143177.3/ It is unchanged code-wise from the v2. -phil. > > same comments about 8143177.2, or it is intended? > >> >> On 18.11.15 3:05, Philip Race wrote: >>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>> >>> This webrev contains the changes accumulated in the harfbuzz project >>> forest >>> that migrate JDK from using ICU for opentype font layout to harfbuzz >>> for >>> the same. >>> >>> The change does not introduce API. It is mostly adding the harfbuzz >>> library. >>> The ICU library remains there but is no longer the default. >>> Eventually (not necessarily in 9) it may be removed once we are >>> comfortable >>> with harfbuzz. >>> You may select ICU by using -Dsun.font.layoutengine=icu >>> >>> You may see which layout engine is in use by using >>> -Dsun.font.layoutengine.verbose=true >>> it will print either "Using harfbuzz", or "Using ICU". >>> >>> The change has no impact on typical Latin script rendering but is a big >>> advance >>> for complex scripts and also applies if you select kerning or ligatures >>> for Latin. >>> However the latter is only detectable if the font implements support >>> for >>> these. >>> By "big advance" I mean that ICU has not been updated to recognise >>> recent opentype features. >>> So harfbuzz should fix a number of things but unexpected changes that >>> look wrong >>> should be reported so we can investigate. >>> >>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>> font information. >>> This means that we do not need a different layer depending on whether >>> freetype or t2k >>> is used. It also enables some caching in the JDK font layer. >>> >>> On macosx harfbuzz does not natively read the AAT tables but will >>> invoke >>> CoreText. >>> This does mean that an AAT font installed on Linux would not be >>> processed but >>> this is not a significant issue since AAT fonts are not found other >>> than >>> on macosx. >>> >>> The majority of the files in the webrev are harfbuzz itself, changed >>> only to comply >>> with JDK whitespace rules. Reviewers should probably concentrate on all >>> of the rest. >>> I've listed it so that all those files are at the beginning and you can >>> ignore all those >>> that follow that are in the "harfbuzz" directory. >>> >>> The harfbuzz version used here is 1.0.6 which is the latest source >>> release (at the time of writing). >>> We expect to update this to keep reasonably current. >>> >>> I would like to push this in on Friday, but at the very latest Monday >>> because of the >>> upcoming Feature Complete date so there are a couple of days to make >>> small >>> tweaks for serious problems but there will be plenty of time after >>> integration to fix >>> remaining problems. >>> >>> -phil. >>> >> >> > > From philip.race at oracle.com Sun Nov 22 17:13:34 2015 From: philip.race at oracle.com (Philip Race) Date: Sun, 22 Nov 2015 09:13:34 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <564FBCED.4030501@oracle.com> References: <564FBCED.4030501@oracle.com> Message-ID: <5651F7BE.8070406@oracle.com> +1. The past testing done by SQE and the intensive testing of correctness and performance plus the various tools that have been run like findbugs all point to this being ready to go .. -phil. On 11/20/15, 4:38 PM, Jim Graham wrote: > Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 > > This webrev contains the changes accumulated in the > Graphics-Rasterizer project forest that add the Marlin AA renderer to > the JDK and make it the default AA RenderingEngine for Java2D. > > The webrev also includes a link to an HTML output of J2DAnalyzer > showing the relative performance on a few basic rendering tests for > Ductus, Marlin, and Pisces. > > This change does not introduce any new API, but it does introduce a > new debugging property to see which RenderingEngine is in use. > > Java2D already supported selecting a RenderingEngine on the fly using: > -Dsun.java2d.renderer= > The default is now set to Marlin. > > You may now also see which RenderingEngine is in use by using (new > with this patch): > -Dsun.java2d.renderer.verbose=true > > The default rendering engine used to be Pisces for OpenJDK and Ductus > for Oracle's products, but the new default will be the new Marlin > renderer for all builds. Pisces is still built and included in > OpenJDK builds and both Pisces and Ductus are still built and included > in Oracle builds, but the user must select those RenderingEngine > implementations on the command line to use them. The alternate > engines may be deprecated and removed over time. > > Marlin already outperforms Pisces in every category by a wide margin > (except for a few basic tests where it has roughly the same > performance to within a margin of error, and roughly the same as > Ductus as well). In addition, Marlin just recently reached a level of > performance comparable to Ductus in single-threaded benchmarks. But, > where Marlin shines is in multi-threaded performance where Ductus had > nearly 0% scalability (and on some benchmarks would often take more > than N times longer to render something with N threads) due to a > required java-level synchronized access to the unprotected singleton > native data structures. Marlin's scalability is very high - in the > 90% range. In MT tests with N threads (N < #cores) Marlin can be > about N times faster or more than Ductus which is a huge win for > server-side use. > > In terms of accuracy, a quick test of comparing the AA renderers > output to a simple Super-Scalar renderer (render an object at 2^N x > 2^N scale and then use a series of N linear interpolation steps to cut > the resolution back to normal size) using 8x8 oversampling shows that > Marlin is, on average, about twice as accurate as Ductus, and close to > 2.5 to 3 times more accurate than Pisces. > > Here is the text summary from analyzing the J2DBench results included > in the webrev above. Note that Pisces is only 40-100% the performance > of Ductus (at best it achieves parity), whereas Marlin is 92-220% the > performance as Ductus (from near parity to over twice as fast): > > Summary: > Ductus Renderer on Mac: > Number of tests: 14 > Overall average: 271435.684621936 > Best spread: 0.25% variance > Worst spread: 0.81% variance > (Basis for results comparison) > > Marlin Renderer on Mac: > Number of tests: 14 > Overall average: 278609.9151360187 > Best spread: 0.24% variance > Worst spread: 0.94% variance > Comparison to basis: > Best result: 219.63% of basis > Worst result: 91.71% of basis > Number of wins: 5 > Number of ties: 5 > Number of losses: 4 > > Pisces Renderer on Mac: > Number of tests: 14 > Overall average: 264688.87069247436 > Best spread: 0.12% variance > Worst spread: 9.28% variance > Comparison to basis: > Best result: 101.71% of basis > Worst result: 40.04% of basis > Number of wins: 0 > Number of ties: 6 > Number of losses: 8 > > For multi-threaded performance, we are still modifying J2DBench to do > MT testing, but meanwhile here are some sample results from a > micro-mt-benchmark that I was using to measure Marlin's benefit over > Ductus, all tests run on my quad-core retina MacBook Pro: > > RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op > Stroking Big Circle took 20001.6ms for 12744 ops = > 1.5694947735404898ms/op > Filling Small Circle took 20000.0ms for 650166 ops = > 0.030761436459304237ms/op > Stroking Small Circle took 20000.2ms for 563230 ops = > 0.03550988808657209ms/op > Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = > 3.1412907711997486ms/op > Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = > 4.958922349529003ms/op > Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = > 48.53754647457627ms/op > Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = > 120.74043964670658ms/op > > RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec > Results for 4 threads: > Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op > Stroking Big Circle took 20000.3ms for 74332 ops = > 0.2690665217672066ms/op > Filling Small Circle took 20000.0ms for 3999239 ops = > 0.0050009547403893585ms/op > Stroking Small Circle took 20000.0ms for 1692821 ops = > 0.011814607555081133ms/op > Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = > 0.6346507143582422ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = > 0.9029244853737812ms/op > Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = > 13.599594945652175ms/op > Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = > 34.748233308492196ms/op > > RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 52844 ops = > 0.37848658839224886ms/op > Stroking Big Circle took 20001.1ms for 39741 ops = > 0.5032854199944641ms/op > Filling Small Circle took 20000.0ms for 1628357 ops = > 0.012282338621076336ms/op > Stroking Small Circle took 20000.1ms for 809256 ops = > 0.024714137085174535ms/op > Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = > 1.3557410718449234ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = > 2.042433472582457ms/op > Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = > 17.572960124561405ms/op > Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = > 59.509273902077155ms/op > > ...jim > From jayathirth.d.v at oracle.com Mon Nov 23 09:39:38 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 23 Nov 2015 01:39:38 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK-8074967: JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata In-Reply-To: References: Message-ID: <09540635-967a-49a0-8196-607bd4ca85fa@default> Hello All, Changed test image used in previous webrev. Because I need image with similar properties in another fix(JDK - 8041501) but content should be white. Changed image and its name in test file no other code changes. Updated Webrev: http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.01/ Please review. Thanks, Jay From: Jayathirth D V Sent: Thursday, November 19, 2015 3:19 PM To: Philip Race; Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Review request for JDK-8074967: JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata Hi Phil/Prasanta, Please review following fix in jdk9: Bug : https://bugs.openjdk.java.net/browse/JDK-8074967 Webrev : http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.00/ Bug : JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata Root cause : In JPEG image if there is no JFIF or EXIF header. We are not checking component ID's to determine color space properly. Third channel component ID (3) is matching the length of componentSpecs length and we are not setting colorspace as YCbCr. It is set to RGB which is wrong. Solution : We should check for id greater than componentSpecs length and not greater than equal. But adding a tighter check to match individual component ID is better. So made changes to match individual component ID with 1, 2 & 3 to set color space as YCbCr. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Nov 23 10:39:41 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 23 Nov 2015 02:39:41 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Message-ID: <9a44a101-b15e-4ef4-8ecc-8041e2d62927@default> Hello All, Please review following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ Issue : Pink discoloration when we read JPEG images without JFIF & EXIF header and having no subsampling. Root cause : We are overriding JPEG color space set in IJG library at imageioJPEG.c without checking component ID's properly when JFIF & EXIF are not there. Decision to change color space is solely done consulting sampling factors. Solution : Added extra check to verify component ID's also before changing color space determined by IJG library when there is no JFIF & EXIF header. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 23 11:06:57 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 23 Nov 2015 16:36:57 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK-8074967: JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata In-Reply-To: <09540635-967a-49a0-8196-607bd4ca85fa@default> References: <09540635-967a-49a0-8196-607bd4ca85fa@default> Message-ID: <5652F351.3060006@oracle.com> Looks ok to me. Regards Prasanta On 11/23/2015 3:09 PM, Jayathirth D V wrote: > > Hello All, > > Changed test image used in previous webrev. Because I need image with > similar properties in another fix(JDK - 8041501) but content should be > white. > > Changed image and its name in test file no other code changes. > > _Updated Webrev: _ > > __ > > http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.01/ > > > Please review. > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Thursday, November 19, 2015 3:19 PM > *To:* Philip Race; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Review request for JDK-8074967: > JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard > metadata > > Hi Phil/Prasanta, > > _Please review following fix in jdk9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8074967 > > Webrev : http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.00/ > > > Bug : JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in > standard metadata > > Root cause : In JPEG image if there is no JFIF or EXIF header. We are > not checking component ID?s to determine color space properly. Third > channel component ID (3) is matching the length of componentSpecs > length and we are not setting colorspace as YCbCr. It is set to RGB > which is wrong. > > Solution : We should check for id greater than componentSpecs length > and not greater than equal. But adding a tighter check to match > individual component ID is better. So made changes to match individual > component ID with 1, 2 & 3 to set color space as YCbCr. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 23 11:13:02 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 23 Nov 2015 16:43:02 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <9a44a101-b15e-4ef4-8ecc-8041e2d62927@default> References: <9a44a101-b15e-4ef4-8ecc-8041e2d62927@default> Message-ID: <5652F4BE.3020609@oracle.com> Looks ok to me. But probably you could check for image width &height programmatically instead of hardcoding to 64 in testcode. Regards Prasanta On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > __ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images without JFIF & > EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in IJG library at > imageioJPEG.c without checking component ID?s properly when JFIF & > EXIF are not there. Decision to change color space is solely done > consulting sampling factors. > > Solution : Added extra check to verify component ID?s also before > changing color space determined by IJG library when there is no JFIF & > EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Nov 23 11:41:04 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 23 Nov 2015 03:41:04 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <5652F4BE.3020609@oracle.com> References: <9a44a101-b15e-4ef4-8ecc-8041e2d62927@default> <5652F4BE.3020609@oracle.com> Message-ID: <901c07ce-dace-42a9-899f-395cb52d2884@default> Hi Prasanta, Thanks for suggestion. I have made related changes and updated the Webrev. Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ Please review. Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 4:43 PM To: Jayathirth D V; 2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Looks ok to me. But probably you could check for image width &height programmatically instead of hardcoding to 64 in testcode. Regards Prasanta On 11/23/2015 4:09 PM, Jayathirth D V wrote: Hello All, Please review following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.00/"http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ Issue : Pink discoloration when we read JPEG images without JFIF & EXIF header and having no subsampling. Root cause : We are overriding JPEG color space set in IJG library at imageioJPEG.c without checking component ID's properly when JFIF & EXIF are not there. Decision to change color space is solely done consulting sampling factors. Solution : Added extra check to verify component ID's also before changing color space determined by IJG library when there is no JFIF & EXIF header. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 23 11:45:17 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 23 Nov 2015 17:15:17 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <901c07ce-dace-42a9-899f-395cb52d2884@default> References: <9a44a101-b15e-4ef4-8ecc-8041e2d62927@default> <5652F4BE.3020609@oracle.com> <901c07ce-dace-42a9-899f-395cb52d2884@default> Message-ID: <5652FC4D.50204@oracle.com> On 11/23/2015 5:11 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for suggestion. I have made related changes and updated the Webrev. > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ > > > Please review. > There's no point getting the width & height repeatedly . You can get it once and use that info in the loop. It's not going to change in runtime, isn;t it :-) Regards Prasanta > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 4:43 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > *Cc:* Philip Race > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Looks ok to me. > But probably you could check for image width &height programmatically > instead of hardcoding to 64 in testcode. > > Regards > Prasanta > > On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images without JFIF & > EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in IJG library > at imageioJPEG.c without checking component ID?s properly when > JFIF & EXIF are not there. Decision to change color space is > solely done consulting sampling factors. > > Solution : Added extra check to verify component ID?s also before > changing color space determined by IJG library when there is no > JFIF & EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayathirth.d.v at oracle.com Mon Nov 23 12:01:33 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Mon, 23 Nov 2015 04:01:33 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Message-ID: <498e0191-cfa8-4446-8b71-fdd551490184@default> Hi Prasanta, Removed repeated usage of getWidth() and getHeight(). Please review. http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 5:15 PM To: Jayathirth D V Cc: Philip Race; 2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header On 11/23/2015 5:11 PM, Jayathirth D V wrote: Hi Prasanta, Thanks for suggestion. I have made related changes and updated the Webrev. Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ Please review. There's no point getting the width & height repeatedly . You can get it once and use that info in the loop. It's not going to change in runtime, isn;t it :-) Regards Prasanta Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 4:43 PM To: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Looks ok to me. But probably you could check for image width &height programmatically instead of hardcoding to 64 in testcode. Regards Prasanta On 11/23/2015 4:09 PM, Jayathirth D V wrote: Hello All, Please review following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.00/"http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ Issue : Pink discoloration when we read JPEG images without JFIF & EXIF header and having no subsampling. Root cause : We are overriding JPEG color space set in IJG library at imageioJPEG.c without checking component ID's properly when JFIF & EXIF are not there. Decision to change color space is solely done consulting sampling factors. Solution : Added extra check to verify component ID's also before changing color space determined by IJG library when there is no JFIF & EXIF header. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Mon Nov 23 12:04:22 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 23 Nov 2015 17:34:22 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <498e0191-cfa8-4446-8b71-fdd551490184@default> References: <498e0191-cfa8-4446-8b71-fdd551490184@default> Message-ID: <565300C6.1000308@oracle.com> Looks ok to me. Regards Prasanta On 11/23/2015 5:31 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Removed repeated usage of getWidth() and getHeight(). Please review. > > http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 5:15 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > On 11/23/2015 5:11 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for suggestion. I have made related changes and updated the > Webrev. > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ > > > Please review. > > There's no point getting the width & height repeatedly . You can get > it once and use that info in the loop. It's not going to change in > runtime, isn;t it :-) > > Regards > Prasanta > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 4:43 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Looks ok to me. > But probably you could check for image width &height > programmatically instead of hardcoding to 64 in testcode. > > Regards > Prasanta > > On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images without > JFIF & EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in IJG > library at imageioJPEG.c without checking component ID?s > properly when JFIF & EXIF are not there. Decision to change > color space is solely done consulting sampling factors. > > Solution : Added extra check to verify component ID?s also > before changing color space determined by IJG library when > there is no JFIF & EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steven.loomis at oracle.com Mon Nov 23 16:21:47 2015 From: steven.loomis at oracle.com (Steven Loomis) Date: Mon, 23 Nov 2015 08:21:47 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <5651F42D.3090403@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> <5651B625.7050105@oracle.com> <5651F42D.3090403@oracle.com> Message-ID: <56533D1B.1010105@oracle.com> 3 looks good On 11/22/2015 8:58 AM, Philip Race wrote: > > > On 11/22/15, 4:33 AM, Sergey Bylokhov wrote: >> On 18.11.15 18:09, Sergey Bylokhov wrote: >>> Hi, Phil. >>> Not an expert here, just a few notes: >>> - Copyright is missing: hb-jdk-font.cc, hb-jdk.h > > hmm. how did I miss that ? Fixed. >>> - HBShaper.c: Do we need a code at 268? probably we can add some todo >>> or remove it? > > I deleted the commented out code. > Uploaded http://cr.openjdk.java.net/~prr/8143177.3/ > It is unchanged code-wise from the v2. > > -phil. > >> >> same comments about 8143177.2, or it is intended? >> >>> >>> On 18.11.15 3:05, Philip Race wrote: >>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>> >>>> This webrev contains the changes accumulated in the harfbuzz project >>>> forest >>>> that migrate JDK from using ICU for opentype font layout to >>>> harfbuzz for >>>> the same. >>>> >>>> The change does not introduce API. It is mostly adding the harfbuzz >>>> library. >>>> The ICU library remains there but is no longer the default. >>>> Eventually (not necessarily in 9) it may be removed once we are >>>> comfortable >>>> with harfbuzz. >>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>> >>>> You may see which layout engine is in use by using >>>> -Dsun.font.layoutengine.verbose=true >>>> it will print either "Using harfbuzz", or "Using ICU". >>>> >>>> The change has no impact on typical Latin script rendering but is a >>>> big >>>> advance >>>> for complex scripts and also applies if you select kerning or >>>> ligatures >>>> for Latin. >>>> However the latter is only detectable if the font implements >>>> support for >>>> these. >>>> By "big advance" I mean that ICU has not been updated to recognise >>>> recent opentype features. >>>> So harfbuzz should fix a number of things but unexpected changes that >>>> look wrong >>>> should be reported so we can investigate. >>>> >>>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>>> font information. >>>> This means that we do not need a different layer depending on whether >>>> freetype or t2k >>>> is used. It also enables some caching in the JDK font layer. >>>> >>>> On macosx harfbuzz does not natively read the AAT tables but will >>>> invoke >>>> CoreText. >>>> This does mean that an AAT font installed on Linux would not be >>>> processed but >>>> this is not a significant issue since AAT fonts are not found other >>>> than >>>> on macosx. >>>> >>>> The majority of the files in the webrev are harfbuzz itself, changed >>>> only to comply >>>> with JDK whitespace rules. Reviewers should probably concentrate on >>>> all >>>> of the rest. >>>> I've listed it so that all those files are at the beginning and you >>>> can >>>> ignore all those >>>> that follow that are in the "harfbuzz" directory. >>>> >>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>> release (at the time of writing). >>>> We expect to update this to keep reasonably current. >>>> >>>> I would like to push this in on Friday, but at the very latest Monday >>>> because of the >>>> upcoming Feature Complete date so there are a couple of days to make >>>> small >>>> tweaks for serious problems but there will be plenty of time after >>>> integration to fix >>>> remaining problems. >>>> >>>> -phil. >>>> >>> >>> >> >> From philip.race at oracle.com Mon Nov 23 17:27:43 2015 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 Nov 2015 09:27:43 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <56533D1B.1010105@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> <5651B625.7050105@oracle.com> <5651F42D.3090403@oracle.com> <56533D1B.1010105@oracle.com> Message-ID: <56534C8F.7010502@oracle.com> Thanks Steven. Sergey & Vadim: I think I've addressed your concerns .. are we good to push ? -phil On 11/23/15, 8:21 AM, Steven Loomis wrote: > 3 looks good > > On 11/22/2015 8:58 AM, Philip Race wrote: >> >> >> On 11/22/15, 4:33 AM, Sergey Bylokhov wrote: >>> On 18.11.15 18:09, Sergey Bylokhov wrote: >>>> Hi, Phil. >>>> Not an expert here, just a few notes: >>>> - Copyright is missing: hb-jdk-font.cc, hb-jdk.h >> >> hmm. how did I miss that ? Fixed. >>>> - HBShaper.c: Do we need a code at 268? probably we can add some >>>> todo >>>> or remove it? >> >> I deleted the commented out code. >> Uploaded http://cr.openjdk.java.net/~prr/8143177.3/ >> It is unchanged code-wise from the v2. >> >> -phil. >> >>> >>> same comments about 8143177.2, or it is intended? >>> >>>> >>>> On 18.11.15 3:05, Philip Race wrote: >>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>>> >>>>> This webrev contains the changes accumulated in the harfbuzz project >>>>> forest >>>>> that migrate JDK from using ICU for opentype font layout to >>>>> harfbuzz for >>>>> the same. >>>>> >>>>> The change does not introduce API. It is mostly adding the harfbuzz >>>>> library. >>>>> The ICU library remains there but is no longer the default. >>>>> Eventually (not necessarily in 9) it may be removed once we are >>>>> comfortable >>>>> with harfbuzz. >>>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>>> >>>>> You may see which layout engine is in use by using >>>>> -Dsun.font.layoutengine.verbose=true >>>>> it will print either "Using harfbuzz", or "Using ICU". >>>>> >>>>> The change has no impact on typical Latin script rendering but is >>>>> a big >>>>> advance >>>>> for complex scripts and also applies if you select kerning or >>>>> ligatures >>>>> for Latin. >>>>> However the latter is only detectable if the font implements >>>>> support for >>>>> these. >>>>> By "big advance" I mean that ICU has not been updated to recognise >>>>> recent opentype features. >>>>> So harfbuzz should fix a number of things but unexpected changes that >>>>> look wrong >>>>> should be reported so we can investigate. >>>>> >>>>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>>>> font information. >>>>> This means that we do not need a different layer depending on whether >>>>> freetype or t2k >>>>> is used. It also enables some caching in the JDK font layer. >>>>> >>>>> On macosx harfbuzz does not natively read the AAT tables but will >>>>> invoke >>>>> CoreText. >>>>> This does mean that an AAT font installed on Linux would not be >>>>> processed but >>>>> this is not a significant issue since AAT fonts are not found >>>>> other than >>>>> on macosx. >>>>> >>>>> The majority of the files in the webrev are harfbuzz itself, changed >>>>> only to comply >>>>> with JDK whitespace rules. Reviewers should probably concentrate >>>>> on all >>>>> of the rest. >>>>> I've listed it so that all those files are at the beginning and >>>>> you can >>>>> ignore all those >>>>> that follow that are in the "harfbuzz" directory. >>>>> >>>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>>> release (at the time of writing). >>>>> We expect to update this to keep reasonably current. >>>>> >>>>> I would like to push this in on Friday, but at the very latest Monday >>>>> because of the >>>>> upcoming Feature Complete date so there are a couple of days to make >>>>> small >>>>> tweaks for serious problems but there will be plenty of time after >>>>> integration to fix >>>>> remaining problems. >>>>> >>>>> -phil. >>>>> >>>> >>>> >>> >>> > From vadim.pakhnushev at oracle.com Mon Nov 23 17:36:44 2015 From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev) Date: Mon, 23 Nov 2015 20:36:44 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <56534C8F.7010502@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> <5651B625.7050105@oracle.com> <5651F42D.3090403@oracle.com> <56533D1B.1010105@oracle.com> <56534C8F.7010502@oracle.com> Message-ID: <56534EAC.6050505@oracle.com> +1 On 23/11/15 20:27, Philip Race wrote: > Thanks Steven. > > Sergey & Vadim: I think I've addressed your concerns .. are we good to > push ? > > -phil > > On 11/23/15, 8:21 AM, Steven Loomis wrote: >> 3 looks good >> >> On 11/22/2015 8:58 AM, Philip Race wrote: >>> >>> >>> On 11/22/15, 4:33 AM, Sergey Bylokhov wrote: >>>> On 18.11.15 18:09, Sergey Bylokhov wrote: >>>>> Hi, Phil. >>>>> Not an expert here, just a few notes: >>>>> - Copyright is missing: hb-jdk-font.cc, hb-jdk.h >>> >>> hmm. how did I miss that ? Fixed. >>>>> - HBShaper.c: Do we need a code at 268? probably we can add some >>>>> todo >>>>> or remove it? >>> >>> I deleted the commented out code. >>> Uploaded http://cr.openjdk.java.net/~prr/8143177.3/ >>> It is unchanged code-wise from the v2. >>> >>> -phil. >>> >>>> >>>> same comments about 8143177.2, or it is intended? >>>> >>>>> >>>>> On 18.11.15 3:05, Philip Race wrote: >>>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>>>> >>>>>> This webrev contains the changes accumulated in the harfbuzz project >>>>>> forest >>>>>> that migrate JDK from using ICU for opentype font layout to >>>>>> harfbuzz for >>>>>> the same. >>>>>> >>>>>> The change does not introduce API. It is mostly adding the harfbuzz >>>>>> library. >>>>>> The ICU library remains there but is no longer the default. >>>>>> Eventually (not necessarily in 9) it may be removed once we are >>>>>> comfortable >>>>>> with harfbuzz. >>>>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>>>> >>>>>> You may see which layout engine is in use by using >>>>>> -Dsun.font.layoutengine.verbose=true >>>>>> it will print either "Using harfbuzz", or "Using ICU". >>>>>> >>>>>> The change has no impact on typical Latin script rendering but is >>>>>> a big >>>>>> advance >>>>>> for complex scripts and also applies if you select kerning or >>>>>> ligatures >>>>>> for Latin. >>>>>> However the latter is only detectable if the font implements >>>>>> support for >>>>>> these. >>>>>> By "big advance" I mean that ICU has not been updated to recognise >>>>>> recent opentype features. >>>>>> So harfbuzz should fix a number of things but unexpected changes >>>>>> that >>>>>> look wrong >>>>>> should be reported so we can investigate. >>>>>> >>>>>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>>>>> font information. >>>>>> This means that we do not need a different layer depending on >>>>>> whether >>>>>> freetype or t2k >>>>>> is used. It also enables some caching in the JDK font layer. >>>>>> >>>>>> On macosx harfbuzz does not natively read the AAT tables but will >>>>>> invoke >>>>>> CoreText. >>>>>> This does mean that an AAT font installed on Linux would not be >>>>>> processed but >>>>>> this is not a significant issue since AAT fonts are not found >>>>>> other than >>>>>> on macosx. >>>>>> >>>>>> The majority of the files in the webrev are harfbuzz itself, changed >>>>>> only to comply >>>>>> with JDK whitespace rules. Reviewers should probably concentrate >>>>>> on all >>>>>> of the rest. >>>>>> I've listed it so that all those files are at the beginning and >>>>>> you can >>>>>> ignore all those >>>>>> that follow that are in the "harfbuzz" directory. >>>>>> >>>>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>>>> release (at the time of writing). >>>>>> We expect to update this to keep reasonably current. >>>>>> >>>>>> I would like to push this in on Friday, but at the very latest >>>>>> Monday >>>>>> because of the >>>>>> upcoming Feature Complete date so there are a couple of days to make >>>>>> small >>>>>> tweaks for serious problems but there will be plenty of time after >>>>>> integration to fix >>>>>> remaining problems. >>>>>> >>>>>> -phil. >>>>>> >>>>> >>>>> >>>> >>>> >> From Sergey.Bylokhov at oracle.com Mon Nov 23 18:42:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Nov 2015 21:42:36 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143177: Integrate harfbuzz opentype layout engine per JEP 258 In-Reply-To: <56534EAC.6050505@oracle.com> References: <564BC0CD.7080207@oracle.com> <564C948F.6010400@oracle.com> <5651B625.7050105@oracle.com> <5651F42D.3090403@oracle.com> <56533D1B.1010105@oracle.com> <56534C8F.7010502@oracle.com> <56534EAC.6050505@oracle.com> Message-ID: <56535E1C.2010705@oracle.com> Looks fine. On 23.11.15 20:36, Vadim Pakhnushev wrote: > +1 > > On 23/11/15 20:27, Philip Race wrote: >> Thanks Steven. >> >> Sergey & Vadim: I think I've addressed your concerns .. are we good to >> push ? >> >> -phil >> >> On 11/23/15, 8:21 AM, Steven Loomis wrote: >>> 3 looks good >>> >>> On 11/22/2015 8:58 AM, Philip Race wrote: >>>> >>>> >>>> On 11/22/15, 4:33 AM, Sergey Bylokhov wrote: >>>>> On 18.11.15 18:09, Sergey Bylokhov wrote: >>>>>> Hi, Phil. >>>>>> Not an expert here, just a few notes: >>>>>> - Copyright is missing: hb-jdk-font.cc, hb-jdk.h >>>> >>>> hmm. how did I miss that ? Fixed. >>>>>> - HBShaper.c: Do we need a code at 268? probably we can add some >>>>>> todo >>>>>> or remove it? >>>> >>>> I deleted the commented out code. >>>> Uploaded http://cr.openjdk.java.net/~prr/8143177.3/ >>>> It is unchanged code-wise from the v2. >>>> >>>> -phil. >>>> >>>>> >>>>> same comments about 8143177.2, or it is intended? >>>>> >>>>>> >>>>>> On 18.11.15 3:05, Philip Race wrote: >>>>>>> Webrev : http://cr.openjdk.java.net/~prr/8143177/ >>>>>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8143177 >>>>>>> >>>>>>> This webrev contains the changes accumulated in the harfbuzz project >>>>>>> forest >>>>>>> that migrate JDK from using ICU for opentype font layout to >>>>>>> harfbuzz for >>>>>>> the same. >>>>>>> >>>>>>> The change does not introduce API. It is mostly adding the harfbuzz >>>>>>> library. >>>>>>> The ICU library remains there but is no longer the default. >>>>>>> Eventually (not necessarily in 9) it may be removed once we are >>>>>>> comfortable >>>>>>> with harfbuzz. >>>>>>> You may select ICU by using -Dsun.font.layoutengine=icu >>>>>>> >>>>>>> You may see which layout engine is in use by using >>>>>>> -Dsun.font.layoutengine.verbose=true >>>>>>> it will print either "Using harfbuzz", or "Using ICU". >>>>>>> >>>>>>> The change has no impact on typical Latin script rendering but is >>>>>>> a big >>>>>>> advance >>>>>>> for complex scripts and also applies if you select kerning or >>>>>>> ligatures >>>>>>> for Latin. >>>>>>> However the latter is only detectable if the font implements >>>>>>> support for >>>>>>> these. >>>>>>> By "big advance" I mean that ICU has not been updated to recognise >>>>>>> recent opentype features. >>>>>>> So harfbuzz should fix a number of things but unexpected changes >>>>>>> that >>>>>>> look wrong >>>>>>> should be reported so we can investigate. >>>>>>> >>>>>>> To use harfbuzz we invoke its shaper and we provide a way to get jdk >>>>>>> font information. >>>>>>> This means that we do not need a different layer depending on >>>>>>> whether >>>>>>> freetype or t2k >>>>>>> is used. It also enables some caching in the JDK font layer. >>>>>>> >>>>>>> On macosx harfbuzz does not natively read the AAT tables but will >>>>>>> invoke >>>>>>> CoreText. >>>>>>> This does mean that an AAT font installed on Linux would not be >>>>>>> processed but >>>>>>> this is not a significant issue since AAT fonts are not found >>>>>>> other than >>>>>>> on macosx. >>>>>>> >>>>>>> The majority of the files in the webrev are harfbuzz itself, changed >>>>>>> only to comply >>>>>>> with JDK whitespace rules. Reviewers should probably concentrate >>>>>>> on all >>>>>>> of the rest. >>>>>>> I've listed it so that all those files are at the beginning and >>>>>>> you can >>>>>>> ignore all those >>>>>>> that follow that are in the "harfbuzz" directory. >>>>>>> >>>>>>> The harfbuzz version used here is 1.0.6 which is the latest source >>>>>>> release (at the time of writing). >>>>>>> We expect to update this to keep reasonably current. >>>>>>> >>>>>>> I would like to push this in on Friday, but at the very latest >>>>>>> Monday >>>>>>> because of the >>>>>>> upcoming Feature Complete date so there are a couple of days to make >>>>>>> small >>>>>>> tweaks for serious problems but there will be plenty of time after >>>>>>> integration to fix >>>>>>> remaining problems. >>>>>>> >>>>>>> -phil. >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>> > -- Best regards, Sergey. From philip.race at oracle.com Mon Nov 23 18:47:50 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Nov 2015 10:47:50 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-6967419 : IndexOutOfBoundsException when drawing PNGs In-Reply-To: <73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default> References: <24aaf3b1-6f23-40b5-a4f2-7994bc1af7eb@default> <563C6FAF.3040600@oracle.com> <48666932-8fbd-4588-9175-07acdd24d78b@default> <5644DD22.2080205@oracle.com> <3ea69749-8b12-43ca-bb53-3db53eb8d26b@default> <564A5000.6040202@oracle.com> <73963f44-6f4b-41e0-a0a8-37e0a7ef9d4d@default> Message-ID: <56535F56.7010906@oracle.com> So you should re-open 8041746 and close it as a dup of 6967419. I am approving 6967419 since it fixes an apparent problem. There may be additional problems but these are still theoretical .. -phil. On 11/17/2015 01:11 AM, Jayathirth D V wrote: > > Hi Phil, > > Thanks for pointing to JDK-8041746 . > > _My observations:_ > > I think with Andrew's test case we are able to identify the problem > submitter might have faced in JDK-6967419 . By deliberately throwing > exception at count 30000L we are trying to reproduce scenario of > possible IOException where client is closing the socket(probably > because of communication problem between client & server) and IDAT > chunk is being written. If we change count to any other number(like > 10L) which relates to writing of data apart from IDAT chunk we don't > see any issue(no exception and cache is closed properly). > > This might explain why submitter is seeing 7 out of 20 fail. > > Also by using the test case we are able to see flushedPos going past > by 4 bytes to Pos when ios.close() is called as mentioned by submitter > in JDK-6967419. So catching the IOException and updating 'startPos' > value, will not result in IndexOutOfBoundsException and ios.close() > will be performed properly. > > Please let us know your inputs. > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Tuesday, November 17, 2015 3:22 AM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > This one reads like it should be obvious but I find it less so .. > The unsatisfying part is that we do not seem to know what caused > the IOException in the customer case. > > Andrew came up with a way to reproduce the symptoms but we really > don't know what caused the exception in the case of the submitter. > It does not seem likely he was 'deliberately' throwing an exception to > mess up his own application. > > I just found this : https://bugs.openjdk.java.net/browse/JDK-8041746 > > The interesting part is that this bug (the one you are working on) > the submitter also wrote that he was using "a ServletOutputStream" > > So consequently I wonder if it was something like what is described in > 8041746 is going on here. It could explain how he sees 7 out of 20 fail. > > Please take a look at that one to have a think about it. > Would your fix help that real world case ? > > -phil. > > On 11/12/2015 08:11 PM, Jayathirth D V wrote: > > Hi Phil, > > I have added public evaluation in bug. Please review. > > Thanks, > > Jay > > *From:*Philip Race > *Sent:* Friday, November 13, 2015 12:11 AM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Please add a *public* evaluation to the bug report. I will look at > it more then .. > > -phil. > > On 11/6/15, 2:20 AM, Jayathirth D V wrote: > > Hi Prasanta, > > As discussed, only in case of write_IDAT there is finally > block which calls ios.finish() which internally calls seek() > with improper startPos. In other cases we are not trying to > access improper startPos because there is no call to > ios.finish(). We can verify this behavior by changing logic > where we throw IOException in test case. > > And I have modified test to not catch IOBE as per your > suggestion. Please find updated Webrev link: > > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.01/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Friday, November 06, 2015 2:45 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK-6967419 : > IndexOutOfBoundsException when drawing PNGs > > Hi Jay, > > looks ok but > I guess you need to do the same for finish() method too in > similar way you did for finishChunk() as finish() is called > from write_IHDR, write_CHRM etc and it calls flushBefore(). > Also, I guess you should not consume IOB Exception and let it > be thrown to user instead of RuntimeException after catching IOBE. > > Regards > Prasanta > > On 11/5/2015 5:25 PM, Jayathirth D V wrote: > > Hello All, > > Please review following fix in jdk9: > > Bug : https://bugs.openjdk.java.net/browse/JDK-6967419 > > Webrev : > http://cr.openjdk.java.net/~rchamyal/jay/6967419/webrev.00/ > > Bug : IndexOutOfBoundsException when drawing PNGs > > Root cause : When user intentionally throws IO Exception > while write is happening. > We call ios.finish() in finally > block of write_IDAT() which internally goes to > finishChunk(). But the startPos of the chunk is still > pointing to present IDAT chunk but flushedPos(streamPos) > is pointing to end of IDAT chunk. > So in finishChunk(), startPos > will be less than flushedPos. This is causing > IndexOutOfBoundException in stream.seek() and cache is not > closed. > > Solution : If IOException is thrown by user, catch the > exception while write is happening and update startPos to > streamPos. So that when seek() happens in finishChunk() we > don't see IndexOutOfBoundsException and cache is closed > properly. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Nov 23 19:07:06 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Nov 2015 22:07:06 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <564FBCED.4030501@oracle.com> References: <564FBCED.4030501@oracle.com> Message-ID: <565363DA.40505@oracle.com> Hi, Jim. It seems that the tests cannot be run via jtreg because of "package marlin" in it. Also as far as I know there is a possibility in the latest jtreg to filter out the system based on the ram, so is it possible to make CrashTest.java automated? RenderingEngine.java: GetPropertyAction can be replaced by GetBooleanAction. On 21.11.15 3:38, Jim Graham wrote: > Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 > > This webrev contains the changes accumulated in the Graphics-Rasterizer > project forest that add the Marlin AA renderer to the JDK and make it > the default AA RenderingEngine for Java2D. > > The webrev also includes a link to an HTML output of J2DAnalyzer showing > the relative performance on a few basic rendering tests for Ductus, > Marlin, and Pisces. > > This change does not introduce any new API, but it does introduce a new > debugging property to see which RenderingEngine is in use. > > Java2D already supported selecting a RenderingEngine on the fly using: > -Dsun.java2d.renderer= > The default is now set to Marlin. > > You may now also see which RenderingEngine is in use by using (new with > this patch): > -Dsun.java2d.renderer.verbose=true > > The default rendering engine used to be Pisces for OpenJDK and Ductus > for Oracle's products, but the new default will be the new Marlin > renderer for all builds. Pisces is still built and included in OpenJDK > builds and both Pisces and Ductus are still built and included in Oracle > builds, but the user must select those RenderingEngine implementations > on the command line to use them. The alternate engines may be > deprecated and removed over time. > > Marlin already outperforms Pisces in every category by a wide margin > (except for a few basic tests where it has roughly the same performance > to within a margin of error, and roughly the same as Ductus as well). In > addition, Marlin just recently reached a level of performance comparable > to Ductus in single-threaded benchmarks. But, where Marlin shines is in > multi-threaded performance where Ductus had nearly 0% scalability (and > on some benchmarks would often take more than N times longer to render > something with N threads) due to a required java-level synchronized > access to the unprotected singleton native data structures. Marlin's > scalability is very high - in the 90% range. In MT tests with N threads > (N < #cores) Marlin can be about N times faster or more than Ductus > which is a huge win for server-side use. > > In terms of accuracy, a quick test of comparing the AA renderers output > to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale > and then use a series of N linear interpolation steps to cut the > resolution back to normal size) using 8x8 oversampling shows that Marlin > is, on average, about twice as accurate as Ductus, and close to 2.5 to 3 > times more accurate than Pisces. > > Here is the text summary from analyzing the J2DBench results included in > the webrev above. Note that Pisces is only 40-100% the performance of > Ductus (at best it achieves parity), whereas Marlin is 92-220% the > performance as Ductus (from near parity to over twice as fast): > > Summary: > Ductus Renderer on Mac: > Number of tests: 14 > Overall average: 271435.684621936 > Best spread: 0.25% variance > Worst spread: 0.81% variance > (Basis for results comparison) > > Marlin Renderer on Mac: > Number of tests: 14 > Overall average: 278609.9151360187 > Best spread: 0.24% variance > Worst spread: 0.94% variance > Comparison to basis: > Best result: 219.63% of basis > Worst result: 91.71% of basis > Number of wins: 5 > Number of ties: 5 > Number of losses: 4 > > Pisces Renderer on Mac: > Number of tests: 14 > Overall average: 264688.87069247436 > Best spread: 0.12% variance > Worst spread: 9.28% variance > Comparison to basis: > Best result: 101.71% of basis > Worst result: 40.04% of basis > Number of wins: 0 > Number of ties: 6 > Number of losses: 8 > > For multi-threaded performance, we are still modifying J2DBench to do MT > testing, but meanwhile here are some sample results from a > micro-mt-benchmark that I was using to measure Marlin's benefit over > Ductus, all tests run on my quad-core retina MacBook Pro: > > RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op > Stroking Big Circle took 20001.6ms for 12744 ops = 1.5694947735404898ms/op > Filling Small Circle took 20000.0ms for 650166 ops = > 0.030761436459304237ms/op > Stroking Small Circle took 20000.2ms for 563230 ops = > 0.03550988808657209ms/op > Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = > 3.1412907711997486ms/op > Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = > 4.958922349529003ms/op > Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = > 48.53754647457627ms/op > Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = > 120.74043964670658ms/op > > RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec > Results for 4 threads: > Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op > Stroking Big Circle took 20000.3ms for 74332 ops = 0.2690665217672066ms/op > Filling Small Circle took 20000.0ms for 3999239 ops = > 0.0050009547403893585ms/op > Stroking Small Circle took 20000.0ms for 1692821 ops = > 0.011814607555081133ms/op > Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = > 0.6346507143582422ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = > 0.9029244853737812ms/op > Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = > 13.599594945652175ms/op > Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = > 34.748233308492196ms/op > > RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 52844 ops = 0.37848658839224886ms/op > Stroking Big Circle took 20001.1ms for 39741 ops = 0.5032854199944641ms/op > Filling Small Circle took 20000.0ms for 1628357 ops = > 0.012282338621076336ms/op > Stroking Small Circle took 20000.1ms for 809256 ops = > 0.024714137085174535ms/op > Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = > 1.3557410718449234ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = > 2.042433472582457ms/op > Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = > 17.572960124561405ms/op > Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = > 59.509273902077155ms/op > > ...jim > -- Best regards, Sergey. From philip.race at oracle.com Mon Nov 23 19:32:32 2015 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 Nov 2015 11:32:32 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: References: <564E965F.5030008@oracle.com> Message-ID: <565369D0.6020004@oracle.com> OK. "Approved" in case there is any doubt on that. -phil. On 11/20/15, 7:35 AM, Brian Burkhalter wrote: > > On Nov 19, 2015, at 7:41 PM, Philip Race > wrote: > >> The changes to pre-existing files look good although it is not apparent >> to me why you deleted this in iio-plugin.properties >> SimpleRenderedImage0=The provided region doesn't intersect with the image bounds >> is it just not used ? > > That is correct. The search > > find src/java.desktop/share/classes -name '*.java' -exec grep > SimpleRenderedImage0 {} \; -print > > does not print anything. > >> The rest I barely "skimmed" but I give it a go. > > OK, thanks. > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Mon Nov 23 19:49:30 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 23 Nov 2015 22:49:30 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: <564E965F.5030008@oracle.com> References: <564E965F.5030008@oracle.com> Message-ID: <56536DCA.5070400@oracle.com> The fix looks fine. Note that this change implement the new SPI readers&writers for ImageIO. But as far as I understand it does not add support of the tiff format to the Toolkit.createImage which use old decoders. I think it is necessary to delete support of old decoders and to replace it with spi? Any objections? On 20.11.15 6:41, Philip Race wrote: > The changes to pre-existing files look good although it is not apparent > to me why you deleted this in iio-plugin.properties > > SimpleRenderedImage0=The provided region doesn't intersect with the > image bounds > > is it just not used ? > > The rest I barely "skimmed" but I give it a go. > > -phil. > > On 11/19/15, 1:48 PM, Brian Burkhalter wrote: >> Please review at your convenience: >> >> Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 >> Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ >> >> This review request pertains to the changes required to integrate Java Image I/O support for TIFF into JDK 9. The two branches of the webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK repository and the top level JDK forest repository, respectively. The latter only adds the new package javax.imageio.plugins.tiff to the list of packages which form the Java API Specification. >> >> The 8143342.00-jdk branch contains the actual source code and HTML changes. There are three subsets of this branch: 1) changes to existing files, 2) new files in the public API, and 3) new files in the non-public implementation. >> >> The portions of the changes to existing files which affect visible API or the behavior of existing API are to add the TIFF reader and writer plugin SPIs to the IIORegistry and to link the TIFF Metadata Format Specification and Usage Notes document from the javax.imageio.metadata package summary. >> >> The new files in the public API are the classes in the javax.imageio.plugins.tiff package, the package summary, and the aforementioned metadata and usage document tiff_metadata.html. The new API is principally concerned with a simplified approach to handling TIFF image metadata. If metadata are not of concern then there should be no need to use the classes in this package. >> >> The new files in the non-public API are the classes in the com.sun.imageio.plugins.tiff package. These classes handle the reading and writing of TIFF image data and metadata. >> >> Thanks, >> >> Brian -- Best regards, Sergey. From philip.race at oracle.com Mon Nov 23 20:20:21 2015 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 Nov 2015 12:20:21 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: <56536DCA.5070400@oracle.com> References: <564E965F.5030008@oracle.com> <56536DCA.5070400@oracle.com> Message-ID: <56537505.8040708@oracle.com> Not sure if you are suggesting TK.createImage migrate to Image I/O to keep them in sync ? Note that already BMP and WBMP are supported only via image I/O and there is no notion of required equivalence between these two image loading mechanisms. -phil. On 11/23/15, 11:49 AM, Sergey Bylokhov wrote: > The fix looks fine. > Note that this change implement the new SPI readers&writers for > ImageIO. But as far as I understand it does not add support of the > tiff format to the Toolkit.createImage which use old decoders. I think > it is necessary to delete support of old decoders and to replace it > with spi? Any objections? > > On 20.11.15 6:41, Philip Race wrote: >> The changes to pre-existing files look good although it is not apparent >> to me why you deleted this in iio-plugin.properties >> >> SimpleRenderedImage0=The provided region doesn't intersect with the >> image bounds >> >> is it just not used ? >> >> The rest I barely "skimmed" but I give it a go. >> >> -phil. >> >> On 11/19/15, 1:48 PM, Brian Burkhalter wrote: >>> Please review at your convenience: >>> >>> Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 >>> Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ >>> >>> This review request pertains to the changes required to integrate >>> Java Image I/O support for TIFF into JDK 9. The two branches of the >>> webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK >>> repository and the top level JDK forest repository, respectively. >>> The latter only adds the new package javax.imageio.plugins.tiff to >>> the list of packages which form the Java API Specification. >>> >>> The 8143342.00-jdk branch contains the actual source code and HTML >>> changes. There are three subsets of this branch: 1) changes to >>> existing files, 2) new files in the public API, and 3) new files in >>> the non-public implementation. >>> >>> The portions of the changes to existing files which affect visible >>> API or the behavior of existing API are to add the TIFF reader and >>> writer plugin SPIs to the IIORegistry and to link the TIFF Metadata >>> Format Specification and Usage Notes document from the >>> javax.imageio.metadata package summary. >>> >>> The new files in the public API are the classes in the >>> javax.imageio.plugins.tiff package, the package summary, and the >>> aforementioned metadata and usage document tiff_metadata.html. The >>> new API is principally concerned with a simplified approach to >>> handling TIFF image metadata. If metadata are not of concern then >>> there should be no need to use the classes in this package. >>> >>> The new files in the non-public API are the classes in the >>> com.sun.imageio.plugins.tiff package. These classes handle the >>> reading and writing of TIFF image data and metadata. >>> >>> Thanks, >>> >>> Brian > > From philip.race at oracle.com Mon Nov 23 20:38:12 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Nov 2015 12:38:12 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <498e0191-cfa8-4446-8b71-fdd551490184@default> References: <498e0191-cfa8-4446-8b71-fdd551490184@default> Message-ID: <56537934.8000308@oracle.com> Rather than adding a comment block, it seems you need to edit the preceding one. * IJG assumes all unidentified 3-channels are YCbCr. 1715 * We assume that only if the second two channels are 1716 * subsampled (either horizontally or vertically). If not, 1717 * we assume RGB. The fix is invalidating that comment but that is intended since (a) following the comment is causing the bug (b) the comment is contradicting the public Metadata spec For the benefit of others, the text in the spec is : ---- If neither marker segment is present, the following procedure is followed: .... For 3- and 4-channel images, the component ids are consulted. If these values are 1-3 for a 3-channel image, then the image is assumed to be YCbCr. ... Otherwise, 3-channel subsampled images are assumed to be YCbCr, 3-channel non-subsampled images are assumed to be RGB --- So here is my suggested replacement text for the existing comment block : --- In the absence of certain markers, IJG has interpreted component id's of [1,2,3] as meaning YCbCr. We follow that interpretation, which is additionally described in the Image I/O JPEG metadata spec. If that condition is not met here the next step here is to examine the subsampling factors If any differ we also assume YCbCr, but if all are the same then we assume RGB This is also described in the Image I/O JPEG metadata spec. -- -phil. On 11/23/2015 04:01 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Removed repeated usage of getWidth() and getHeight(). Please review. > > http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 5:15 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > On 11/23/2015 5:11 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for suggestion. I have made related changes and updated the > Webrev. > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ > > > Please review. > > There's no point getting the width & height repeatedly . You can get > it once and use that info in the loop. It's not going to change in > runtime, isn;t it :-) > > Regards > Prasanta > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 4:43 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Looks ok to me. > But probably you could check for image width &height > programmatically instead of hardcoding to 64 in testcode. > > Regards > Prasanta > > On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images without > JFIF & EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in IJG > library at imageioJPEG.c without checking component ID's > properly when JFIF & EXIF are not there. Decision to change > color space is solely done consulting sampling factors. > > Solution : Added extra check to verify component ID's also > before changing color space determined by IJG library when > there is no JFIF & EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.race at oracle.com Mon Nov 23 21:27:08 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Nov 2015 13:27:08 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK-8074967: JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard metadata In-Reply-To: <09540635-967a-49a0-8196-607bd4ca85fa@default> References: <09540635-967a-49a0-8196-607bd4ca85fa@default> Message-ID: <565384AC.3080500@oracle.com> Approved. -phil. On 11/23/2015 01:39 AM, Jayathirth D V wrote: > > Hello All, > > Changed test image used in previous webrev. Because I need image with > similar properties in another fix(JDK - 8041501) but content should be > white. > > Changed image and its name in test file no other code changes. > > _Updated Webrev: _ > > __ > > http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.01/ > > > Please review. > > Thanks, > > Jay > > *From:*Jayathirth D V > *Sent:* Thursday, November 19, 2015 3:19 PM > *To:* Philip Race; Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Review request for JDK-8074967: > JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in standard > metadata > > Hi Phil/Prasanta, > > _Please review following fix in jdk9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8074967 > > Webrev : http://cr.openjdk.java.net/~rchamyal/jay/8074967/webrev.00/ > > > Bug : JPEGImageReader incorrectly identifies YCbCr JPEGs as RGB in > standard metadata > > Root cause : In JPEG image if there is no JFIF or EXIF header. We are > not checking component ID's to determine color space properly. Third > channel component ID (3) is matching the length of componentSpecs > length and we are not setting colorspace as YCbCr. It is set to RGB > which is wrong. > > Solution : We should check for id greater than componentSpecs length > and not greater than equal. But adding a tighter check to match > individual component ID is better. So made changes to match individual > component ID with 1, 2 & 3 to set color space as YCbCr. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james.graham at oracle.com Mon Nov 23 21:31:29 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 23 Nov 2015 13:31:29 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <564FBCED.4030501@oracle.com> References: <564FBCED.4030501@oracle.com> Message-ID: <565385B1.2070308@oracle.com> An updated webrev to fix the automated tests. The only changes are to remove the package statements from the files in test/sun/java2d/marlin/*.java: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.01/ The benchmark results were copied over from webrev.00 since there are no expected changes in behavior or performance... ...jim On 11/20/15 4:38 PM, Jim Graham wrote: > Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 > > This webrev contains the changes accumulated in the Graphics-Rasterizer > project forest that add the Marlin AA renderer to the JDK and make it > the default AA RenderingEngine for Java2D. > > The webrev also includes a link to an HTML output of J2DAnalyzer showing > the relative performance on a few basic rendering tests for Ductus, > Marlin, and Pisces. > > This change does not introduce any new API, but it does introduce a new > debugging property to see which RenderingEngine is in use. > > Java2D already supported selecting a RenderingEngine on the fly using: > -Dsun.java2d.renderer= > The default is now set to Marlin. > > You may now also see which RenderingEngine is in use by using (new with > this patch): > -Dsun.java2d.renderer.verbose=true > > The default rendering engine used to be Pisces for OpenJDK and Ductus > for Oracle's products, but the new default will be the new Marlin > renderer for all builds. Pisces is still built and included in OpenJDK > builds and both Pisces and Ductus are still built and included in Oracle > builds, but the user must select those RenderingEngine implementations > on the command line to use them. The alternate engines may be > deprecated and removed over time. > > Marlin already outperforms Pisces in every category by a wide margin > (except for a few basic tests where it has roughly the same performance > to within a margin of error, and roughly the same as Ductus as well). In > addition, Marlin just recently reached a level of performance comparable > to Ductus in single-threaded benchmarks. But, where Marlin shines is in > multi-threaded performance where Ductus had nearly 0% scalability (and > on some benchmarks would often take more than N times longer to render > something with N threads) due to a required java-level synchronized > access to the unprotected singleton native data structures. Marlin's > scalability is very high - in the 90% range. In MT tests with N threads > (N < #cores) Marlin can be about N times faster or more than Ductus > which is a huge win for server-side use. > > In terms of accuracy, a quick test of comparing the AA renderers output > to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale > and then use a series of N linear interpolation steps to cut the > resolution back to normal size) using 8x8 oversampling shows that Marlin > is, on average, about twice as accurate as Ductus, and close to 2.5 to 3 > times more accurate than Pisces. > > Here is the text summary from analyzing the J2DBench results included in > the webrev above. Note that Pisces is only 40-100% the performance of > Ductus (at best it achieves parity), whereas Marlin is 92-220% the > performance as Ductus (from near parity to over twice as fast): > > Summary: > Ductus Renderer on Mac: > Number of tests: 14 > Overall average: 271435.684621936 > Best spread: 0.25% variance > Worst spread: 0.81% variance > (Basis for results comparison) > > Marlin Renderer on Mac: > Number of tests: 14 > Overall average: 278609.9151360187 > Best spread: 0.24% variance > Worst spread: 0.94% variance > Comparison to basis: > Best result: 219.63% of basis > Worst result: 91.71% of basis > Number of wins: 5 > Number of ties: 5 > Number of losses: 4 > > Pisces Renderer on Mac: > Number of tests: 14 > Overall average: 264688.87069247436 > Best spread: 0.12% variance > Worst spread: 9.28% variance > Comparison to basis: > Best result: 101.71% of basis > Worst result: 40.04% of basis > Number of wins: 0 > Number of ties: 6 > Number of losses: 8 > > For multi-threaded performance, we are still modifying J2DBench to do MT > testing, but meanwhile here are some sample results from a > micro-mt-benchmark that I was using to measure Marlin's benefit over > Ductus, all tests run on my quad-core retina MacBook Pro: > > RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op > Stroking Big Circle took 20001.6ms for 12744 ops = 1.5694947735404898ms/op > Filling Small Circle took 20000.0ms for 650166 ops = > 0.030761436459304237ms/op > Stroking Small Circle took 20000.2ms for 563230 ops = > 0.03550988808657209ms/op > Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = > 3.1412907711997486ms/op > Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = > 4.958922349529003ms/op > Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = > 48.53754647457627ms/op > Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = > 120.74043964670658ms/op > > RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec > Results for 4 threads: > Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op > Stroking Big Circle took 20000.3ms for 74332 ops = 0.2690665217672066ms/op > Filling Small Circle took 20000.0ms for 3999239 ops = > 0.0050009547403893585ms/op > Stroking Small Circle took 20000.0ms for 1692821 ops = > 0.011814607555081133ms/op > Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = > 0.6346507143582422ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = > 0.9029244853737812ms/op > Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = > 13.599594945652175ms/op > Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = > 34.748233308492196ms/op > > RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc > Results for 4 threads: > Filling Big Circle took 20000.7ms for 52844 ops = 0.37848658839224886ms/op > Stroking Big Circle took 20001.1ms for 39741 ops = 0.5032854199944641ms/op > Filling Small Circle took 20000.0ms for 1628357 ops = > 0.012282338621076336ms/op > Stroking Small Circle took 20000.1ms for 809256 ops = > 0.024714137085174535ms/op > Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = > 1.3557410718449234ms/op > Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = > 2.042433472582457ms/op > Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = > 17.572960124561405ms/op > Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = > 59.509273902077155ms/op > > ...jim > From philip.race at oracle.com Mon Nov 23 22:23:09 2015 From: philip.race at oracle.com (Phil Race) Date: Mon, 23 Nov 2015 14:23:09 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <565385B1.2070308@oracle.com> References: <564FBCED.4030501@oracle.com> <565385B1.2070308@oracle.com> Message-ID: <565391CD.7060601@oracle.com> Approved. -phil. On 11/23/2015 01:31 PM, Jim Graham wrote: > An updated webrev to fix the automated tests. The only changes are to > remove the package statements from the files in > test/sun/java2d/marlin/*.java: > > http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.01/ > > The benchmark results were copied over from webrev.00 since there are > no expected changes in behavior or performance... > > ...jim > > On 11/20/15 4:38 PM, Jim Graham wrote: >> Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 >> >> This webrev contains the changes accumulated in the Graphics-Rasterizer >> project forest that add the Marlin AA renderer to the JDK and make it >> the default AA RenderingEngine for Java2D. >> >> The webrev also includes a link to an HTML output of J2DAnalyzer showing >> the relative performance on a few basic rendering tests for Ductus, >> Marlin, and Pisces. >> >> This change does not introduce any new API, but it does introduce a new >> debugging property to see which RenderingEngine is in use. >> >> Java2D already supported selecting a RenderingEngine on the fly using: >> -Dsun.java2d.renderer= >> The default is now set to Marlin. >> >> You may now also see which RenderingEngine is in use by using (new with >> this patch): >> -Dsun.java2d.renderer.verbose=true >> >> The default rendering engine used to be Pisces for OpenJDK and Ductus >> for Oracle's products, but the new default will be the new Marlin >> renderer for all builds. Pisces is still built and included in OpenJDK >> builds and both Pisces and Ductus are still built and included in Oracle >> builds, but the user must select those RenderingEngine implementations >> on the command line to use them. The alternate engines may be >> deprecated and removed over time. >> >> Marlin already outperforms Pisces in every category by a wide margin >> (except for a few basic tests where it has roughly the same performance >> to within a margin of error, and roughly the same as Ductus as well). In >> addition, Marlin just recently reached a level of performance comparable >> to Ductus in single-threaded benchmarks. But, where Marlin shines is in >> multi-threaded performance where Ductus had nearly 0% scalability (and >> on some benchmarks would often take more than N times longer to render >> something with N threads) due to a required java-level synchronized >> access to the unprotected singleton native data structures. Marlin's >> scalability is very high - in the 90% range. In MT tests with N threads >> (N < #cores) Marlin can be about N times faster or more than Ductus >> which is a huge win for server-side use. >> >> In terms of accuracy, a quick test of comparing the AA renderers output >> to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale >> and then use a series of N linear interpolation steps to cut the >> resolution back to normal size) using 8x8 oversampling shows that Marlin >> is, on average, about twice as accurate as Ductus, and close to 2.5 to 3 >> times more accurate than Pisces. >> >> Here is the text summary from analyzing the J2DBench results included in >> the webrev above. Note that Pisces is only 40-100% the performance of >> Ductus (at best it achieves parity), whereas Marlin is 92-220% the >> performance as Ductus (from near parity to over twice as fast): >> >> Summary: >> Ductus Renderer on Mac: >> Number of tests: 14 >> Overall average: 271435.684621936 >> Best spread: 0.25% variance >> Worst spread: 0.81% variance >> (Basis for results comparison) >> >> Marlin Renderer on Mac: >> Number of tests: 14 >> Overall average: 278609.9151360187 >> Best spread: 0.24% variance >> Worst spread: 0.94% variance >> Comparison to basis: >> Best result: 219.63% of basis >> Worst result: 91.71% of basis >> Number of wins: 5 >> Number of ties: 5 >> Number of losses: 4 >> >> Pisces Renderer on Mac: >> Number of tests: 14 >> Overall average: 264688.87069247436 >> Best spread: 0.12% variance >> Worst spread: 9.28% variance >> Comparison to basis: >> Best result: 101.71% of basis >> Worst result: 40.04% of basis >> Number of wins: 0 >> Number of ties: 6 >> Number of losses: 8 >> >> For multi-threaded performance, we are still modifying J2DBench to do MT >> testing, but meanwhile here are some sample results from a >> micro-mt-benchmark that I was using to measure Marlin's benefit over >> Ductus, all tests run on my quad-core retina MacBook Pro: >> >> RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc >> Results for 4 threads: >> Filling Big Circle took 20000.7ms for 17513 ops = >> 1.1420479872666018ms/op >> Stroking Big Circle took 20001.6ms for 12744 ops = >> 1.5694947735404898ms/op >> Filling Small Circle took 20000.0ms for 650166 ops = >> 0.030761436459304237ms/op >> Stroking Small Circle took 20000.2ms for 563230 ops = >> 0.03550988808657209ms/op >> Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = >> 3.1412907711997486ms/op >> Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = >> 4.958922349529003ms/op >> Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = >> 48.53754647457627ms/op >> Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = >> 120.74043964670658ms/op >> >> RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec >> Results for 4 threads: >> Filling Big Circle took 20000.4ms for 93097 ops = >> 0.2148343392483109ms/op >> Stroking Big Circle took 20000.3ms for 74332 ops = >> 0.2690665217672066ms/op >> Filling Small Circle took 20000.0ms for 3999239 ops = >> 0.0050009547403893585ms/op >> Stroking Small Circle took 20000.0ms for 1692821 ops = >> 0.011814607555081133ms/op >> Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = >> 0.6346507143582422ms/op >> Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = >> 0.9029244853737812ms/op >> Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = >> 13.599594945652175ms/op >> Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = >> 34.748233308492196ms/op >> >> RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc >> Results for 4 threads: >> Filling Big Circle took 20000.7ms for 52844 ops = >> 0.37848658839224886ms/op >> Stroking Big Circle took 20001.1ms for 39741 ops = >> 0.5032854199944641ms/op >> Filling Small Circle took 20000.0ms for 1628357 ops = >> 0.012282338621076336ms/op >> Stroking Small Circle took 20000.1ms for 809256 ops = >> 0.024714137085174535ms/op >> Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = >> 1.3557410718449234ms/op >> Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = >> 2.042433472582457ms/op >> Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = >> 17.572960124561405ms/op >> Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = >> 59.509273902077155ms/op >> >> ...jim >> From james.graham at oracle.com Mon Nov 23 22:38:56 2015 From: james.graham at oracle.com (Jim Graham) Date: Mon, 23 Nov 2015 14:38:56 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <565363DA.40505@oracle.com> References: <564FBCED.4030501@oracle.com> <565363DA.40505@oracle.com> Message-ID: <56539580.3030701@oracle.com> I missed this in my last round of changes. It's not critical, though, so I'll file an issue to fix it up. We may also be tweaking how we control/advertise the RenderingEngine in the future so we can deal with it in that case... ...jim On 11/23/15 11:07 AM, Sergey Bylokhov wrote: > RenderingEngine.java: > GetPropertyAction can be replaced by GetBooleanAction. From jvanek at redhat.com Tue Nov 24 09:16:21 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 24 Nov 2015 10:16:21 +0100 Subject: [OpenJDK 2D-Dev] Duplicated (or better multiplicated) image-decoder resolvers in openjdk In-Reply-To: <564E8FCF.6060807@oracle.com> References: <56336CE6.2010106@redhat.com> <564CB148.90300@oracle.com> <564E8FCF.6060807@oracle.com> Message-ID: <56542AE5.8000605@redhat.com> On 11/20/2015 04:13 AM, Philip Race wrote: > Yes this is really 2d rather than AWT. > Image I/O dates from 1.0 whereas Toolkit.createImage(..) dates from 1.0 > > They share almost no implementation, what there is that is shared is the IJG JPEG library. > > It would be nice if TK.createImage just delegated to Image I/O. Yes that is exactly what I had in mind. > Some years ago we considered something like this and step #1 was to make sure > about compatibility and performance and a fair amount of work was done but > we did not have resources to follow up. At this time it could be a JDK10 goal > for step #2 to investigate and decide whether it makes sense. > There are still issues like when or if colour space conversion is done. > > I do not off-hand remember if there is any obstacle to icedtea's TK image > support simply "understanding" .ico's since I do not recall any definitive > list in the SE spec of what TK.createImage may (or may not) support. > > And you can create an image i/o plugin too but not as a standard plugin. I ended up with imsage SPI provider for ico. Works fine as wrapper around basic java's bmp and jpg SPIs Phil, tahnk you very much for your kind and explaining answer. I'm crossing fingers for jdk10 to settle those multiplicated resolvers as verifying step #1 is not (from my small touch) the simplest way to do... J. > > -phil > > On 11/18/15, 9:11 AM, Sergey Bylokhov wrote: >> Hi, Jiri. >> This question also related to 2d area(cc) >> >> I think it is possible to use the PNGImageReader(spi) instead of sun.awt.PNGImageDecoder, which >> will allow automatically handle the nondefault image formats. But as far as I know there are no >> plan to do it in jdk9. >> >> On 30.10.15 16:13, Jiri Vanek wrote: >>> Hello! >>> >>> Recently I was doing ico imagereader-spi provider for icedtea-web >>> (which is javaws (and plugin) implementation for openjdk) >>> Yes, ico is stupid, but is in web standards so having its support is >>> just natural. However, providing spi did not solved the problem i was >>> bugged for. >>> >>> After small debugging why, I found that eg SunToolkit.createImage and >>> relatives - which are quite heavily used, do not honour ImageIO SPIs and >>> are going by its own way: >>> >>> >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/FileImageSource.java#l50 >>> >>> >>> for file >>> and >>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/InputStreamImageSource.java#l213 >>> >>> >>> for stream >>> >>> Well maybe its legacy bourden, but it is reimplementing what image SPIs >>> providers via (apis canDecodeInput[2]) do. Long story short - >>> reimplementing wheel and duplicated (very duplicated) code. >>> >>> I wonted to ask, if there are any plans in jdk9 to fix this. If no, what >>> can I do to make it happen. >>> >>> >>> Thanx! >>> J. >>> >>> >>> [2] >>> https://docs.oracle.com/javase/7/docs/api/javax/imageio/spi/ImageReaderSpi.html#canDecodeInput%28java.lang.Object%29 >>> >>> >>> https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageReader.html >> >> From jvanek at redhat.com Tue Nov 24 09:17:29 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 24 Nov 2015 10:17:29 +0100 Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <564CB29C.10200@redhat.com> References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com> <56449312.2000005@oracle.com> <564CB29C.10200@redhat.com> Message-ID: <56542B29.90202@redhat.com> On 11/18/2015 06:17 PM, Jiri Vanek wrote: > On 11/12/2015 02:24 PM, Sergey Bylokhov wrote: >> Hi, Jiri. >> This is a valid point, did you file a new CR for this issue? ping? >> > > Hello! > > here it is: > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/ > > Patch: > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/ > and reprodcuer > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java > > > Reproducer can be easily turned to jtreg if wonted. > > The patch is for 8, but is valid also for 9, except the path to file. > I will adapt it to 9 once you are ok with it (or you may on your own, depends on you) > > J. > > >> On 09.11.15 15:45, Alexander Scherbatiy wrote: >>> On 11/7/2015 11:38 AM, Jiri Vanek wrote: >>>> Hello! >>>> >>>> Looking to imageIO.java (if this is bad thread, please redirect me!) >>> >>> 2d-dev alias should be also the right place to ask image related >>> questions in AWT. >>> >>> Thanks, >>> Alexandr. >>> >>>> when reading images >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 >>>> >>>> >>>> >>>> and ending at: >>>> >>>> // Perform mark/reset as a defensive measure >>>> // even though plug-ins are supposed to take >>>> // care of it. >>>> boolean canDecode = false; >>>> if (stream != null) { >>>> stream.mark(); >>>> } >>>> canDecode = spi.canDecodeInput(input); >>>> if (stream != null) { >>>> stream.reset(); >>>> } >>>> return canDecode; >>>> >>>> I'm wondering, why stream.reset(); is not in finaly block: >>>> >>>> // Perform mark/reset as a defensive measure >>>> // even though plug-ins are supposed to take >>>> // care of it. >>>> boolean canDecode = false; >>>> if (stream != null) { >>>> stream.mark(); >>>> } >>>> try{ >>>> canDecode = spi.canDecodeInput(input); >>>> } finally { >>>> if (stream != null) { >>>> stream.reset(); >>>> } >>>> } >>>> return canDecode; >>>> >>>> >>>> Eg png and bmp decoders can are throwing IIOException when header is >>>> corrutped. That pretty definitely sure killer of stream mark stacks. >>>> You yourselves write : //Perform mark/reset as a defensive measure >>>> even though plug-ins are supposed to take care of it. >>>> So if densive, then try/finaly please. >>>> >>>> I did not check if this changed in 9 but if not....Please. This is >>>> makig work on custom image plugins, for image formats which just wraps >>>> another bmp/png and are expecting corrupted headers preatty hards. >>>> >>>> >>>> J. >>> >> >> > From jayathirth.d.v at oracle.com Tue Nov 24 09:39:34 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 24 Nov 2015 01:39:34 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <56537934.8000308@oracle.com> References: <498e0191-cfa8-4446-8b71-fdd551490184@default> <56537934.8000308@oracle.com> Message-ID: Hi Phil, I have replaced already present comment block with proper comments , since it was contradicting Metadata spec. And removed extra comments added by me. Please review updated webrev: http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ Thanks, Jay From: Phil Race Sent: Tuesday, November 24, 2015 2:08 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Rather than adding a comment block, it seems you need to edit the preceding one. * IJG assumes all unidentified 3-channels are YCbCr. 1715 * We assume that only if the second two channels are 1716 * subsampled (either horizontally or vertically). If not, 1717 * we assume RGB. The fix is invalidating that comment but that is intended since (a) following the comment is causing the bug (b) the comment is contradicting the public Metadata spec For the benefit of others, the text in the spec is : ---- If neither marker segment is present, the following procedure is followed: .... For 3- and 4-channel images, the component ids are consulted. If these values are 1-3 for a 3-channel image, then the image is assumed to be YCbCr. ... Otherwise, 3-channel subsampled images are assumed to be YCbCr, 3-channel non-subsampled images are assumed to be RGB --- So here is my suggested replacement text for the existing comment block : --- In the absence of certain markers, IJG has interpreted component id's of [1,2,3] as meaning YCbCr. We follow that interpretation, which is additionally described in the Image I/O JPEG metadata spec. If that condition is not met here the next step here is to examine the subsampling factors If any differ we also assume YCbCr, but if all are the same then we assume RGB This is also described in the Image I/O JPEG metadata spec. -- -phil. On 11/23/2015 04:01 AM, Jayathirth D V wrote: Hi Prasanta, Removed repeated usage of getWidth() and getHeight(). Please review. HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.02/"http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 5:15 PM To: Jayathirth D V Cc: Philip Race; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header On 11/23/2015 5:11 PM, Jayathirth D V wrote: Hi Prasanta, Thanks for suggestion. I have made related changes and updated the Webrev. Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.01/"http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ Please review. There's no point getting the width & height repeatedly . You can get it once and use that info in the loop. It's not going to change in runtime, isn;t it :-) Regards Prasanta Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 4:43 PM To: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Looks ok to me. But probably you could check for image width &height programmatically instead of hardcoding to 64 in testcode. Regards Prasanta On 11/23/2015 4:09 PM, Jayathirth D V wrote: Hello All, Please review following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.00/"http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ Issue : Pink discoloration when we read JPEG images without JFIF & EXIF header and having no subsampling. Root cause : We are overriding JPEG color space set in IJG library at imageioJPEG.c without checking component ID's properly when JFIF & EXIF are not there. Decision to change color space is solely done consulting sampling factors. Solution : Added extra check to verify component ID's also before changing color space determined by IJG library when there is no JFIF & EXIF header. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasanta.sadhukhan at oracle.com Tue Nov 24 10:22:35 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Tue, 24 Nov 2015 15:52:35 +0530 Subject: [OpenJDK 2D-Dev] [9]RFR: JDK-7063986, , Wrong JNi method call in font scaler Message-ID: <56543A6B.2050705@oracle.com> Hi All, Please review a simple fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-7063986 webrev: http://cr.openjdk.java.net/~psadhukhan/7063986/webrev/ It is found that the JNI invocation sun.font.Type1Font.readFile() from freeTypefontScaler.c is wrong. readFile() type is void but JNI uses CallObjectMethod instead of CallVoidMethod. Rectified JNI invocation in native to use correct CallVoidMethod. Did not add any reg. testcase as I am not sure how to test this via a testcase. Regards Prasanta From alexandr.scherbatiy at oracle.com Tue Nov 24 13:07:24 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Tue, 24 Nov 2015 16:07:24 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <564F4360.3070609@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> Message-ID: <5654610C.2090302@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8069348/webrev.01/ - The given image sizes are transformed in the SG2D.doCopyArea method. The copyArea() methods are updated accordingly. - OGLSurfaceData.copyArea() method is updated to process scaled transforms. - The test which uses copyArea() method for VolatileImage is added. I left the test which moves internal frames for the Swing testing purposes. Thanks, Alexandr. On 11/20/2015 6:59 PM, Jim Graham wrote: > In terms of consolidating the code... > > Since SD.copyArea is an internal API, we could simply specify that it > takes pixel coordinates and assumes COPY semantics so it is up to SG2D > to verify the transform and compState and perform appropriate > coordinate transformations before asking the SD to do the dirty work. > I'm not sure why we left so much veto power up to the SD class there... > > ...jim > > On 11/20/15 7:38 AM, Sergey Bylokhov wrote: >> On 20.11.15 14:49, Alexander Scherbatiy wrote: >>> >>> Hello, >>> >>> Could you review the fix: >>> bug: https://bugs.openjdk.java.net/browse/JDK-8069348 >>> webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 >>> >>> For some reasons Blit operation does not properly work in the >>> SunGraphics2D.copyArea() method >>> with scaled transform neither on Windows nor on Mac OS X. >>> I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() >>> does not properly handle Blit operation >> >> Interesting. >> >>> >>> The current solution updates D3DSurfaceData.copyArea() to handle >>> scaled graphics in the same way >>> as it has been already done for the CGLSurfaceData (see JDK-8000629 >>> [macosx] Blurry rendering with Java 7 on Retina display). >> >> Note that this fix does not help ogl on windows right? because on >> windows the usual ogl blit should be used since the fix for retina was >> osx specific. Or it works properly? >> >>> >>> May be there is a way to avoid the code duplication: put it to some >>> SurfaceDataUtils class (it also >>> requires adding parent copyArea() method to BufferedRenderPipe) or >>> something else. I am not sure about the best option. >> >> This is up to the 2d team, but I think yes, it will be better to move it >> somewhere because after the current fix the different pipelines will >> behave differently on different platforms for a different >> transformations =( >> >>> >>> >>> Thanks, >>> Alexandr. >>> >> >> From Sergey.Bylokhov at oracle.com Tue Nov 24 13:23:07 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Nov 2015 16:23:07 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <565385B1.2070308@oracle.com> References: <564FBCED.4030501@oracle.com> <565385B1.2070308@oracle.com> Message-ID: <565464BB.1090109@oracle.com> Looks fine. On 24.11.15 0:31, Jim Graham wrote: > An updated webrev to fix the automated tests. The only changes are to > remove the package statements from the files in > test/sun/java2d/marlin/*.java: > > http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.01/ > > The benchmark results were copied over from webrev.00 since there are no > expected changes in behavior or performance... > > ...jim > > On 11/20/15 4:38 PM, Jim Graham wrote: >> Webrev: http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8076529 >> >> This webrev contains the changes accumulated in the Graphics-Rasterizer >> project forest that add the Marlin AA renderer to the JDK and make it >> the default AA RenderingEngine for Java2D. >> >> The webrev also includes a link to an HTML output of J2DAnalyzer showing >> the relative performance on a few basic rendering tests for Ductus, >> Marlin, and Pisces. >> >> This change does not introduce any new API, but it does introduce a new >> debugging property to see which RenderingEngine is in use. >> >> Java2D already supported selecting a RenderingEngine on the fly using: >> -Dsun.java2d.renderer= >> The default is now set to Marlin. >> >> You may now also see which RenderingEngine is in use by using (new with >> this patch): >> -Dsun.java2d.renderer.verbose=true >> >> The default rendering engine used to be Pisces for OpenJDK and Ductus >> for Oracle's products, but the new default will be the new Marlin >> renderer for all builds. Pisces is still built and included in OpenJDK >> builds and both Pisces and Ductus are still built and included in Oracle >> builds, but the user must select those RenderingEngine implementations >> on the command line to use them. The alternate engines may be >> deprecated and removed over time. >> >> Marlin already outperforms Pisces in every category by a wide margin >> (except for a few basic tests where it has roughly the same performance >> to within a margin of error, and roughly the same as Ductus as well). In >> addition, Marlin just recently reached a level of performance comparable >> to Ductus in single-threaded benchmarks. But, where Marlin shines is in >> multi-threaded performance where Ductus had nearly 0% scalability (and >> on some benchmarks would often take more than N times longer to render >> something with N threads) due to a required java-level synchronized >> access to the unprotected singleton native data structures. Marlin's >> scalability is very high - in the 90% range. In MT tests with N threads >> (N < #cores) Marlin can be about N times faster or more than Ductus >> which is a huge win for server-side use. >> >> In terms of accuracy, a quick test of comparing the AA renderers output >> to a simple Super-Scalar renderer (render an object at 2^N x 2^N scale >> and then use a series of N linear interpolation steps to cut the >> resolution back to normal size) using 8x8 oversampling shows that Marlin >> is, on average, about twice as accurate as Ductus, and close to 2.5 to 3 >> times more accurate than Pisces. >> >> Here is the text summary from analyzing the J2DBench results included in >> the webrev above. Note that Pisces is only 40-100% the performance of >> Ductus (at best it achieves parity), whereas Marlin is 92-220% the >> performance as Ductus (from near parity to over twice as fast): >> >> Summary: >> Ductus Renderer on Mac: >> Number of tests: 14 >> Overall average: 271435.684621936 >> Best spread: 0.25% variance >> Worst spread: 0.81% variance >> (Basis for results comparison) >> >> Marlin Renderer on Mac: >> Number of tests: 14 >> Overall average: 278609.9151360187 >> Best spread: 0.24% variance >> Worst spread: 0.94% variance >> Comparison to basis: >> Best result: 219.63% of basis >> Worst result: 91.71% of basis >> Number of wins: 5 >> Number of ties: 5 >> Number of losses: 4 >> >> Pisces Renderer on Mac: >> Number of tests: 14 >> Overall average: 264688.87069247436 >> Best spread: 0.12% variance >> Worst spread: 9.28% variance >> Comparison to basis: >> Best result: 101.71% of basis >> Worst result: 40.04% of basis >> Number of wins: 0 >> Number of ties: 6 >> Number of losses: 8 >> >> For multi-threaded performance, we are still modifying J2DBench to do MT >> testing, but meanwhile here are some sample results from a >> micro-mt-benchmark that I was using to measure Marlin's benefit over >> Ductus, all tests run on my quad-core retina MacBook Pro: >> >> RenderingEngine = sun.dc.DuctusRenderingEngine at 2ea524fc >> Results for 4 threads: >> Filling Big Circle took 20000.7ms for 17513 ops = 1.1420479872666018ms/op >> Stroking Big Circle took 20001.6ms for 12744 ops = >> 1.5694947735404898ms/op >> Filling Small Circle took 20000.0ms for 650166 ops = >> 0.030761436459304237ms/op >> Stroking Small Circle took 20000.2ms for 563230 ops = >> 0.03550988808657209ms/op >> Filling Small Even-Odd Polygon took 20003.7ms for 6368 ops = >> 3.1412907711997486ms/op >> Stroking Small Even-Odd Polygon took 20004.3ms for 4034 ops = >> 4.958922349529003ms/op >> Filling Big Even-Odd Polygon took 20046.0ms for 413 ops = >> 48.53754647457627ms/op >> Stroking Big Even-Odd Polygon took 20163.7ms for 167 ops = >> 120.74043964670658ms/op >> >> RenderingEngine = sun.java2d.marlin.MarlinRenderingEngine at 3550b8ec >> Results for 4 threads: >> Filling Big Circle took 20000.4ms for 93097 ops = 0.2148343392483109ms/op >> Stroking Big Circle took 20000.3ms for 74332 ops = >> 0.2690665217672066ms/op >> Filling Small Circle took 20000.0ms for 3999239 ops = >> 0.0050009547403893585ms/op >> Stroking Small Circle took 20000.0ms for 1692821 ops = >> 0.011814607555081133ms/op >> Filling Small Even-Odd Polygon took 20001.0ms for 31515 ops = >> 0.6346507143582422ms/op >> Stroking Small Even-Odd Polygon took 20001.6ms for 22152 ops = >> 0.9029244853737812ms/op >> Filling Big Even-Odd Polygon took 20018.6ms for 1472 ops = >> 13.599594945652175ms/op >> Stroking Big Even-Odd Polygon took 20049.7ms for 577 ops = >> 34.748233308492196ms/op >> >> RenderingEngine = sun.java2d.pisces.PiscesRenderingEngine at 2ea524fc >> Results for 4 threads: >> Filling Big Circle took 20000.7ms for 52844 ops = >> 0.37848658839224886ms/op >> Stroking Big Circle took 20001.1ms for 39741 ops = >> 0.5032854199944641ms/op >> Filling Small Circle took 20000.0ms for 1628357 ops = >> 0.012282338621076336ms/op >> Stroking Small Circle took 20000.1ms for 809256 ops = >> 0.024714137085174535ms/op >> Filling Small Even-Odd Polygon took 20002.6ms for 14754 ops = >> 1.3557410718449234ms/op >> Stroking Small Even-Odd Polygon took 20001.6ms for 9793 ops = >> 2.042433472582457ms/op >> Filling Big Even-Odd Polygon took 20033.2ms for 1140 ops = >> 17.572960124561405ms/op >> Stroking Big Even-Odd Polygon took 20054.6ms for 337 ops = >> 59.509273902077155ms/op >> >> ...jim >> -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Nov 24 14:50:27 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Nov 2015 17:50:27 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <5654610C.2090302@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> Message-ID: <56547933.5080005@oracle.com> Looks fine to me. On 24.11.15 16:07, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8069348/webrev.01/ > > - The given image sizes are transformed in the SG2D.doCopyArea method. > The copyArea() methods are updated accordingly. > - OGLSurfaceData.copyArea() method is updated to process scaled > transforms. > - The test which uses copyArea() method for VolatileImage is added. I > left the test which moves internal frames for the Swing testing purposes. > > Thanks, > Alexandr. > > > On 11/20/2015 6:59 PM, Jim Graham wrote: >> In terms of consolidating the code... >> >> Since SD.copyArea is an internal API, we could simply specify that it >> takes pixel coordinates and assumes COPY semantics so it is up to SG2D >> to verify the transform and compState and perform appropriate >> coordinate transformations before asking the SD to do the dirty work. >> I'm not sure why we left so much veto power up to the SD class there... >> >> ...jim >> >> On 11/20/15 7:38 AM, Sergey Bylokhov wrote: >>> On 20.11.15 14:49, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8069348 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 >>>> >>>> For some reasons Blit operation does not properly work in the >>>> SunGraphics2D.copyArea() method >>>> with scaled transform neither on Windows nor on Mac OS X. >>>> I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() >>>> does not properly handle Blit operation >>> >>> Interesting. >>> >>>> >>>> The current solution updates D3DSurfaceData.copyArea() to handle >>>> scaled graphics in the same way >>>> as it has been already done for the CGLSurfaceData (see JDK-8000629 >>>> [macosx] Blurry rendering with Java 7 on Retina display). >>> >>> Note that this fix does not help ogl on windows right? because on >>> windows the usual ogl blit should be used since the fix for retina was >>> osx specific. Or it works properly? >>> >>>> >>>> May be there is a way to avoid the code duplication: put it to some >>>> SurfaceDataUtils class (it also >>>> requires adding parent copyArea() method to BufferedRenderPipe) or >>>> something else. I am not sure about the best option. >>> >>> This is up to the 2d team, but I think yes, it will be better to move it >>> somewhere because after the current fix the different pipelines will >>> behave differently on different platforms for a different >>> transformations =( >>> >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> > -- Best regards, Sergey. From philip.race at oracle.com Tue Nov 24 18:25:29 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 24 Nov 2015 10:25:29 -0800 Subject: [OpenJDK 2D-Dev] [9]RFR: JDK-7063986, , Wrong JNi method call in font scaler In-Reply-To: <56543A6B.2050705@oracle.com> References: <56543A6B.2050705@oracle.com> Message-ID: <5654AB99.9030503@oracle.com> approved. -phil. On 11/24/2015 02:22 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a simple fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-7063986 > webrev: http://cr.openjdk.java.net/~psadhukhan/7063986/webrev/ > > It is found that the JNI invocation sun.font.Type1Font.readFile() from > freeTypefontScaler.c is wrong. > readFile() type is void but JNI uses CallObjectMethod instead of > CallVoidMethod. > Rectified JNI invocation in native to use correct CallVoidMethod. > > Did not add any reg. testcase as I am not sure how to test this via a > testcase. > > Regards > Prasanta > From philip.race at oracle.com Tue Nov 24 18:26:44 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 24 Nov 2015 10:26:44 -0800 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: References: <498e0191-cfa8-4446-8b71-fdd551490184@default> <56537934.8000308@oracle.com> Message-ID: <5654ABE4.5040306@oracle.com> Approved. -phil. On 11/24/2015 01:39 AM, Jayathirth D V wrote: > > Hi Phil, > > I have replaced already present comment block with proper comments , > since it was contradicting Metadata spec. And removed extra comments > added by me. > > _Please review updated webrev:_ > > http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Tuesday, November 24, 2015 2:08 AM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Rather than adding a comment block, it seems you need to edit the > preceding one. > > * IJG assumes all unidentified 3-channels are YCbCr. > 1715 * We assume that only if the second two channels are > 1716 * subsampled (either horizontally or vertically). If not, > 1717 * we assume RGB. > > The fix is invalidating that comment but that is intended since > (a) following the comment is causing the bug > (b) the comment is contradicting the public Metadata spec > > For the benefit of others, the text in the spec is : > ---- > If neither marker segment is present, the following procedure is followed: .... > For 3- and 4-channel images, the component ids are consulted. If these > values are 1-3 for a 3-channel image, then the image is assumed to be YCbCr. > > ... Otherwise, 3-channel subsampled images are assumed to be YCbCr, > 3-channel non-subsampled images are assumed to be RGB > --- > > So here is my suggested replacement text for the existing comment block : > --- > In the absence of certain markers, IJG has interpreted component id's of [1,2,3] as meaning YCbCr. > We follow that interpretation, which is additionally described in the Image I/O JPEG metadata spec. > If that condition is not met here the next step here is to examine the subsampling factors > If any differ we also assume YCbCr, but if all are the same then we assume RGB > This is also described in the Image I/O JPEG metadata spec. > > -- > > -phil. > > On 11/23/2015 04:01 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Removed repeated usage of getWidth() and getHeight(). Please review. > > http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 5:15 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > On 11/23/2015 5:11 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for suggestion. I have made related changes and updated > the Webrev. > > Webrev : http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ > > > Please review. > > There's no point getting the width & height repeatedly . You can > get it once and use that info in the loop. It's not going to > change in runtime, isn;t it :-) > > Regards > Prasanta > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 4:43 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK - > 8041501 : ImageIO reader is not capable of reading JPEGs > without JFIF header > > Looks ok to me. > But probably you could check for image width &height > programmatically instead of hardcoding to 64 in testcode. > > Regards > Prasanta > > On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : > http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images > without JFIF & EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in IJG > library at imageioJPEG.c without checking component ID's > properly when JFIF & EXIF are not there. Decision to > change color space is solely done consulting sampling factors. > > Solution : Added extra check to verify component ID's also > before changing color space determined by IJG library when > there is no JFIF & EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergey.Bylokhov at oracle.com Tue Nov 24 19:20:40 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 24 Nov 2015 22:20:40 +0300 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: <56537505.8040708@oracle.com> References: <564E965F.5030008@oracle.com> <56536DCA.5070400@oracle.com> <56537505.8040708@oracle.com> Message-ID: <5654B888.9000502@oracle.com> On 23.11.15 23:20, Philip Race wrote: > Not sure if you are suggesting TK.createImage migrate to Image I/O to > keep them in sync ? Yes, I suggest to drop the old decoders and replace them by imageio. > Note that already BMP and WBMP are supported only via image I/O and > there is > no notion of required equivalence between these two image loading > mechanisms. > > -phil. > > On 11/23/15, 11:49 AM, Sergey Bylokhov wrote: >> The fix looks fine. >> Note that this change implement the new SPI readers&writers for >> ImageIO. But as far as I understand it does not add support of the >> tiff format to the Toolkit.createImage which use old decoders. I think >> it is necessary to delete support of old decoders and to replace it >> with spi? Any objections? >> >> On 20.11.15 6:41, Philip Race wrote: >>> The changes to pre-existing files look good although it is not apparent >>> to me why you deleted this in iio-plugin.properties >>> >>> SimpleRenderedImage0=The provided region doesn't intersect with the >>> image bounds >>> >>> is it just not used ? >>> >>> The rest I barely "skimmed" but I give it a go. >>> >>> -phil. >>> >>> On 11/19/15, 1:48 PM, Brian Burkhalter wrote: >>>> Please review at your convenience: >>>> >>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 >>>> Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ >>>> >>>> This review request pertains to the changes required to integrate >>>> Java Image I/O support for TIFF into JDK 9. The two branches of the >>>> webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK >>>> repository and the top level JDK forest repository, respectively. >>>> The latter only adds the new package javax.imageio.plugins.tiff to >>>> the list of packages which form the Java API Specification. >>>> >>>> The 8143342.00-jdk branch contains the actual source code and HTML >>>> changes. There are three subsets of this branch: 1) changes to >>>> existing files, 2) new files in the public API, and 3) new files in >>>> the non-public implementation. >>>> >>>> The portions of the changes to existing files which affect visible >>>> API or the behavior of existing API are to add the TIFF reader and >>>> writer plugin SPIs to the IIORegistry and to link the TIFF Metadata >>>> Format Specification and Usage Notes document from the >>>> javax.imageio.metadata package summary. >>>> >>>> The new files in the public API are the classes in the >>>> javax.imageio.plugins.tiff package, the package summary, and the >>>> aforementioned metadata and usage document tiff_metadata.html. The >>>> new API is principally concerned with a simplified approach to >>>> handling TIFF image metadata. If metadata are not of concern then >>>> there should be no need to use the classes in this package. >>>> >>>> The new files in the non-public API are the classes in the >>>> com.sun.imageio.plugins.tiff package. These classes handle the >>>> reading and writing of TIFF image data and metadata. >>>> >>>> Thanks, >>>> >>>> Brian >> >> -- Best regards, Sergey. From philip.race at oracle.com Tue Nov 24 19:30:18 2015 From: philip.race at oracle.com (Philip Race) Date: Tue, 24 Nov 2015 11:30:18 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8143342: Integrate Java Image I/O support for TIFF per JEP 262 In-Reply-To: <5654B888.9000502@oracle.com> References: <564E965F.5030008@oracle.com> <56536DCA.5070400@oracle.com> <56537505.8040708@oracle.com> <5654B888.9000502@oracle.com> Message-ID: <5654BACA.2060502@oracle.com> On 11/24/15, 11:20 AM, Sergey Bylokhov wrote: > On 23.11.15 23:20, Philip Race wrote: >> Not sure if you are suggesting TK.createImage migrate to Image I/O to >> keep them in sync ? > > Yes, I suggest to drop the old decoders and replace them by imageio. As I mentioned in a separate thread there are some significant differences in these two APIs so this is not a simple "swap". -phil. > >> Note that already BMP and WBMP are supported only via image I/O and >> there is >> no notion of required equivalence between these two image loading >> mechanisms. >> >> -phil. >> >> On 11/23/15, 11:49 AM, Sergey Bylokhov wrote: >>> The fix looks fine. >>> Note that this change implement the new SPI readers&writers for >>> ImageIO. But as far as I understand it does not add support of the >>> tiff format to the Toolkit.createImage which use old decoders. I think >>> it is necessary to delete support of old decoders and to replace it >>> with spi? Any objections? >>> >>> On 20.11.15 6:41, Philip Race wrote: >>>> The changes to pre-existing files look good although it is not >>>> apparent >>>> to me why you deleted this in iio-plugin.properties >>>> >>>> SimpleRenderedImage0=The provided region doesn't intersect with the >>>> image bounds >>>> >>>> is it just not used ? >>>> >>>> The rest I barely "skimmed" but I give it a go. >>>> >>>> -phil. >>>> >>>> On 11/19/15, 1:48 PM, Brian Burkhalter wrote: >>>>> Please review at your convenience: >>>>> >>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8143342 >>>>> Webrev: http://cr.openjdk.java.net/~bpb/8143342/8143342.00/ >>>>> >>>>> This review request pertains to the changes required to integrate >>>>> Java Image I/O support for TIFF into JDK 9. The two branches of the >>>>> webrev, 8143342.00-jdk and 8143342.00-jdkforest, are for the JDK >>>>> repository and the top level JDK forest repository, respectively. >>>>> The latter only adds the new package javax.imageio.plugins.tiff to >>>>> the list of packages which form the Java API Specification. >>>>> >>>>> The 8143342.00-jdk branch contains the actual source code and HTML >>>>> changes. There are three subsets of this branch: 1) changes to >>>>> existing files, 2) new files in the public API, and 3) new files in >>>>> the non-public implementation. >>>>> >>>>> The portions of the changes to existing files which affect visible >>>>> API or the behavior of existing API are to add the TIFF reader and >>>>> writer plugin SPIs to the IIORegistry and to link the TIFF Metadata >>>>> Format Specification and Usage Notes document from the >>>>> javax.imageio.metadata package summary. >>>>> >>>>> The new files in the public API are the classes in the >>>>> javax.imageio.plugins.tiff package, the package summary, and the >>>>> aforementioned metadata and usage document tiff_metadata.html. The >>>>> new API is principally concerned with a simplified approach to >>>>> handling TIFF image metadata. If metadata are not of concern then >>>>> there should be no need to use the classes in this package. >>>>> >>>>> The new files in the non-public API are the classes in the >>>>> com.sun.imageio.plugins.tiff package. These classes handle the >>>>> reading and writing of TIFF image data and metadata. >>>>> >>>>> Thanks, >>>>> >>>>> Brian >>> >>> > > From james.graham at oracle.com Tue Nov 24 21:30:24 2015 From: james.graham at oracle.com (Jim Graham) Date: Tue, 24 Nov 2015 13:30:24 -0800 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <5654610C.2090302@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> Message-ID: <5654D6F0.3090702@oracle.com> Hi Alexandr, OSXOffScreenSD.java - what are these "rdar:" references? OSXOffscreenSD.java - since this method just refers back to the SG2D, how is it any better than just returning false and letting SG2D's general copyArea deal with the issue? Also, SG2D.drawImage() is not guaranteed to handle overlapping copyareas so arguably it could fail - but I suppose the assertion is that the drawImage to such destinations happens to deal with overlapping areas? Is that asserted or tested anywhere? Also, this method claims that the Windows version ignores the "light clip", but it doesn't. In fact, if there is a clip then GDIcopyarea punts to the general version. I find a lot to worry about in this implementation and I wonder how well it was tested...? (Note that other than the two issues I point out below with this file, those concerns were not raised by this fix - it looks like a fairly faithful translation of the questionable implementation to the new scheme (ignoring the x/y bug below)) OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make this part of the SD.copyArea contract, that the coordinates are in device space and the SD method should not concern itself with the SG2D transform? OSXOffscreenSD.java, line 511 - double check your x/y's OSXSD.java, line 1097 - typos: heavyweight, clipped X11SD.java & XRSD.java - (not an issue with this fix, but a question for future work) needExposures? Do any of the other copyarea implementations send repaint events? Shouldn't this be hard-coded to false? More investigation is likely needed here. CopyAreaTest.java, line 52 - typo "BACKGROUND_COLOR" CopyAreaTest.java, line 61 - rounding is not the same operation that SG2D uses, but it works anyway? CopyAreaTest.java, line 86 - perhaps move the scale to after you fill the background? CopyAreaTest.java, line 94 - "Y + i * DX" => DY (that's odd, how did the test pass?) CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah, this may mask the error in line 94 above...? ...jim On 11/24/15 5:07 AM, Alexander Scherbatiy wrote: > > Hello, > > Could you review the updated fix: > http://cr.openjdk.java.net/~alexsch/8069348/webrev.01/ > > - The given image sizes are transformed in the SG2D.doCopyArea method. > The copyArea() methods are updated accordingly. > - OGLSurfaceData.copyArea() method is updated to process scaled > transforms. > - The test which uses copyArea() method for VolatileImage is added. I > left the test which moves internal frames for the Swing testing purposes. > > Thanks, > Alexandr. > > > On 11/20/2015 6:59 PM, Jim Graham wrote: >> In terms of consolidating the code... >> >> Since SD.copyArea is an internal API, we could simply specify that it >> takes pixel coordinates and assumes COPY semantics so it is up to SG2D >> to verify the transform and compState and perform appropriate >> coordinate transformations before asking the SD to do the dirty work. >> I'm not sure why we left so much veto power up to the SD class there... >> >> ...jim >> >> On 11/20/15 7:38 AM, Sergey Bylokhov wrote: >>> On 20.11.15 14:49, Alexander Scherbatiy wrote: >>>> >>>> Hello, >>>> >>>> Could you review the fix: >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8069348 >>>> webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 >>>> >>>> For some reasons Blit operation does not properly work in the >>>> SunGraphics2D.copyArea() method >>>> with scaled transform neither on Windows nor on Mac OS X. >>>> I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() >>>> does not properly handle Blit operation >>> >>> Interesting. >>> >>>> >>>> The current solution updates D3DSurfaceData.copyArea() to handle >>>> scaled graphics in the same way >>>> as it has been already done for the CGLSurfaceData (see JDK-8000629 >>>> [macosx] Blurry rendering with Java 7 on Retina display). >>> >>> Note that this fix does not help ogl on windows right? because on >>> windows the usual ogl blit should be used since the fix for retina was >>> osx specific. Or it works properly? >>> >>>> >>>> May be there is a way to avoid the code duplication: put it to some >>>> SurfaceDataUtils class (it also >>>> requires adding parent copyArea() method to BufferedRenderPipe) or >>>> something else. I am not sure about the best option. >>> >>> This is up to the 2d team, but I think yes, it will be better to move it >>> somewhere because after the current fix the different pipelines will >>> behave differently on different platforms for a different >>> transformations =( >>> >>>> >>>> >>>> Thanks, >>>> Alexandr. >>>> >>> >>> > From jayathirth.d.v at oracle.com Wed Nov 25 06:38:35 2015 From: jayathirth.d.v at oracle.com (Jayathirth D V) Date: Tue, 24 Nov 2015 22:38:35 -0800 (PST) Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <5654ABE4.5040306@oracle.com> References: <498e0191-cfa8-4446-8b71-fdd551490184@default> <56537934.8000308@oracle.com> <5654ABE4.5040306@oracle.com> Message-ID: <4becb72e-a35a-411f-bc49-8894be8ff4d5@default> Hi Prasanta, Please review updated webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.03/"http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ Thanks, Jay From: Phil Race Sent: Tuesday, November 24, 2015 11:57 PM To: Jayathirth D V Cc: Prasanta Sadhukhan; 2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Approved. -phil. On 11/24/2015 01:39 AM, Jayathirth D V wrote: Hi Phil, I have replaced already present comment block with proper comments , since it was contradicting Metadata spec. And removed extra comments added by me. Please review updated webrev: HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.03/"http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ Thanks, Jay From: Phil Race Sent: Tuesday, November 24, 2015 2:08 AM To: Jayathirth D V Cc: Prasanta Sadhukhan; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Rather than adding a comment block, it seems you need to edit the preceding one. * IJG assumes all unidentified 3-channels are YCbCr. 1715 * We assume that only if the second two channels are 1716 * subsampled (either horizontally or vertically). If not, 1717 * we assume RGB. The fix is invalidating that comment but that is intended since (a) following the comment is causing the bug (b) the comment is contradicting the public Metadata spec For the benefit of others, the text in the spec is : ---- If neither marker segment is present, the following procedure is followed: .... For 3- and 4-channel images, the component ids are consulted. If these values are 1-3 for a 3-channel image, then the image is assumed to be YCbCr. ... Otherwise, 3-channel subsampled images are assumed to be YCbCr, 3-channel non-subsampled images are assumed to be RGB --- So here is my suggested replacement text for the existing comment block : --- In the absence of certain markers, IJG has interpreted component id's of [1,2,3] as meaning YCbCr. We follow that interpretation, which is additionally described in the Image I/O JPEG metadata spec. If that condition is not met here the next step here is to examine the subsampling factors If any differ we also assume YCbCr, but if all are the same then we assume RGB This is also described in the Image I/O JPEG metadata spec. -- -phil. On 11/23/2015 04:01 AM, Jayathirth D V wrote: Hi Prasanta, Removed repeated usage of getWidth() and getHeight(). Please review. HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.02/"http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 5:15 PM To: Jayathirth D V Cc: Philip Race; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header On 11/23/2015 5:11 PM, Jayathirth D V wrote: Hi Prasanta, Thanks for suggestion. I have made related changes and updated the Webrev. Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.01/"http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ Please review. There's no point getting the width & height repeatedly . You can get it once and use that info in the loop. It's not going to change in runtime, isn;t it :-) Regards Prasanta Thanks, Jay From: prasanta sadhukhan Sent: Monday, November 23, 2015 4:43 PM To: Jayathirth D V; HYPERLINK "mailto:2d-dev at openjdk.java.net"2d-dev at openjdk.java.net Cc: Philip Race Subject: Re: Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header Looks ok to me. But probably you could check for image width &height programmatically instead of hardcoding to 64 in testcode. Regards Prasanta On 11/23/2015 4:09 PM, Jayathirth D V wrote: Hello All, Please review following fix in JDK9: Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 Webrev : HYPERLINK "http://cr.openjdk.java.net/%7Ejdv/8041501/webrev.00/"http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ Issue : Pink discoloration when we read JPEG images without JFIF & EXIF header and having no subsampling. Root cause : We are overriding JPEG color space set in IJG library at imageioJPEG.c without checking component ID's properly when JFIF & EXIF are not there. Decision to change color space is solely done consulting sampling factors. Solution : Added extra check to verify component ID's also before changing color space determined by IJG library when there is no JFIF & EXIF header. Thanks, Jay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rajeev.chamyal at oracle.com Wed Nov 25 09:40:09 2015 From: rajeev.chamyal at oracle.com (Rajeev Chamyal) Date: Wed, 25 Nov 2015 01:40:09 -0800 (PST) Subject: [OpenJDK 2D-Dev] [9]RFR: JDK-7063986, , Wrong JNi method call in font scaler In-Reply-To: <5654AB99.9030503@oracle.com> References: <56543A6B.2050705@oracle.com> <5654AB99.9030503@oracle.com> Message-ID: <978c7d6b-eaea-4d83-8c41-9fb6d95b0b4d@default> The fix looks good to me. Regards, Rajeev Chamyal -----Original Message----- From: Phil Race Sent: 24 November 2015 23:55 To: prasanta sadhukhan Cc: 2d-dev at openjdk.java.net; Rajeev Chamyal Subject: Re: [9]RFR: JDK-7063986,,Wrong JNi method call in font scaler approved. -phil. On 11/24/2015 02:22 AM, prasanta sadhukhan wrote: > Hi All, > > Please review a simple fix for jdk9 > Bug: https://bugs.openjdk.java.net/browse/JDK-7063986 > webrev: http://cr.openjdk.java.net/~psadhukhan/7063986/webrev/ > > It is found that the JNI invocation sun.font.Type1Font.readFile() from > freeTypefontScaler.c is wrong. > readFile() type is void but JNI uses CallObjectMethod instead of > CallVoidMethod. > Rectified JNI invocation in native to use correct CallVoidMethod. > > Did not add any reg. testcase as I am not sure how to test this via a > testcase. > > Regards > Prasanta > From prasanta.sadhukhan at oracle.com Wed Nov 25 09:42:53 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Wed, 25 Nov 2015 15:12:53 +0530 Subject: [OpenJDK 2D-Dev] Review request for JDK - 8041501 : ImageIO reader is not capable of reading JPEGs without JFIF header In-Reply-To: <4becb72e-a35a-411f-bc49-8894be8ff4d5@default> References: <498e0191-cfa8-4446-8b71-fdd551490184@default> <56537934.8000308@oracle.com> <5654ABE4.5040306@oracle.com> <4becb72e-a35a-411f-bc49-8894be8ff4d5@default> Message-ID: <5655829D.4060004@oracle.com> +1 Regards Prasanta On 11/25/2015 12:08 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Please review updated webrev : > > http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Tuesday, November 24, 2015 11:57 PM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Approved. > > -phil. > > On 11/24/2015 01:39 AM, Jayathirth D V wrote: > > Hi Phil, > > I have replaced already present comment block with proper comments > , since it was contradicting Metadata spec. And removed extra > comments added by me. > > _Please review updated webrev:_ > > http://cr.openjdk.java.net/~jdv/8041501/webrev.03/ > > > Thanks, > > Jay > > *From:*Phil Race > *Sent:* Tuesday, November 24, 2015 2:08 AM > *To:* Jayathirth D V > *Cc:* Prasanta Sadhukhan; 2d-dev at openjdk.java.net > > *Subject:* Re: Review request for JDK - 8041501 : > ImageIO reader is not capable of reading JPEGs without JFIF header > > Rather than adding a comment block, it seems you need to edit the > preceding one. > > * IJG assumes all unidentified 3-channels are YCbCr. > > 1715 * We assume that only if the second two channels are > > 1716 * subsampled (either horizontally or vertically). If not, > > 1717 * we assume RGB. > > > > The fix is invalidating that comment but that is intended since > > (a) following the comment is causing the bug > > (b) the comment is contradicting the public Metadata spec > > > > For the benefit of others, the text in the spec is : > > ---- > > If neither marker segment is present, the following procedure is followed: .... > > For 3- and 4-channel images, the component ids are consulted. If these > > values are 1-3 for a 3-channel image, then the image is assumed to be YCbCr. > > > > ... Otherwise, 3-channel subsampled images are assumed to be YCbCr, > > 3-channel non-subsampled images are assumed to be RGB > > --- > > > > So here is my suggested replacement text for the existing comment block : > > --- > > In the absence of certain markers, IJG has interpreted component id's of [1,2,3] as meaning YCbCr. > > We follow that interpretation, which is additionally described in the Image I/O JPEG metadata spec. > > If that condition is not met here the next step here is to examine the subsampling factors > > If any differ we also assume YCbCr, but if all are the same then we assume RGB > > This is also described in the Image I/O JPEG metadata spec. > > -- > > -phil. > > On 11/23/2015 04:01 AM, Jayathirth D V wrote: > > Hi Prasanta, > > Removed repeated usage of getWidth() and getHeight(). Please > review. > > http://cr.openjdk.java.net/~jdv/8041501/webrev.02/ > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 5:15 PM > *To:* Jayathirth D V > *Cc:* Philip Race; 2d-dev at openjdk.java.net > > *Subject:* Re: Review request for JDK - > 8041501 : ImageIO reader is not capable of reading JPEGs > without JFIF header > > On 11/23/2015 5:11 PM, Jayathirth D V wrote: > > Hi Prasanta, > > Thanks for suggestion. I have made related changes and > updated the Webrev. > > Webrev : > http://cr.openjdk.java.net/~jdv/8041501/webrev.01/ > > > Please review. > > There's no point getting the width & height repeatedly . You > can get it once and use that info in the loop. It's not going > to change in runtime, isn;t it :-) > > Regards > Prasanta > > > > Thanks, > > Jay > > *From:*prasanta sadhukhan > *Sent:* Monday, November 23, 2015 4:43 PM > *To:* Jayathirth D V; 2d-dev at openjdk.java.net > > *Cc:* Philip Race > *Subject:* Re: Review request for JDK - > 8041501 : ImageIO reader is not capable of reading JPEGs > without JFIF header > > Looks ok to me. > But probably you could check for image width &height > programmatically instead of hardcoding to 64 in testcode. > > Regards > Prasanta > > On 11/23/2015 4:09 PM, Jayathirth D V wrote: > > Hello All, > > _Please review following fix in JDK9:_ > > Bug : https://bugs.openjdk.java.net/browse/JDK-8041501 > > Webrev : > http://cr.openjdk.java.net/~jdv/8041501/webrev.00/ > > > Issue : Pink discoloration when we read JPEG images > without JFIF & EXIF header and having no subsampling. > > Root cause : We are overriding JPEG color space set in > IJG library at imageioJPEG.c without checking > component ID?s properly when JFIF & EXIF are not > there. Decision to change color space is solely done > consulting sampling factors. > > Solution : Added extra check to verify component ID?s > also before changing color space determined by IJG > library when there is no JFIF & EXIF header. > > Thanks, > > Jay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bourges.laurent at gmail.com Wed Nov 25 10:35:19 2015 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Wed, 25 Nov 2015 11:35:19 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <565385B1.2070308@oracle.com> References: <564FBCED.4030501@oracle.com> <565385B1.2070308@oracle.com> Message-ID: Hi Jim, It seems that your changes made on the java2d patch (webrev.01) are not present in the GR repository. See: http://hg.openjdk.java.net/graphics-rasterizer/jdk9/jdk/ Could you merge (back) ? or later ... PS: I am synchronizing all my Marlin variants on my laptop (GR, github branches ...) to be able to go forward. Thanks, Laurent 2015-11-23 22:31 GMT+01:00 Jim Graham : > An updated webrev to fix the automated tests. The only changes are to > remove the package statements from the files in > test/sun/java2d/marlin/*.java: > > http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.01/ > > The benchmark results were copied over from webrev.00 since there are no > expected changes in behavior or performance... -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu.andrew at redhat.com Wed Nov 25 17:53:48 2015 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 25 Nov 2015 12:53:48 -0500 (EST) Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <56542B29.90202@redhat.com> References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com> <56449312.2000005@oracle.com> <564CB29C.10200@redhat.com> <56542B29.90202@redhat.com> Message-ID: <1720362320.17383226.1448474028843.JavaMail.zimbra@redhat.com> ----- Original Message ----- > On 11/18/2015 06:17 PM, Jiri Vanek wrote: > > On 11/12/2015 02:24 PM, Sergey Bylokhov wrote: > >> Hi, Jiri. > >> This is a valid point, did you file a new CR for this issue? > > ping? > > >> > > > > Hello! > > > > here it is: > > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/ > > > > Patch: > > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/ > > and reprodcuer > > https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java > > > > > > Reproducer can be easily turned to jtreg if wonted. > > > > The patch is for 8, but is valid also for 9, except the path to file. > > I will adapt it to 9 once you are ok with it (or you may on your own, > > depends on you) > > > > J. > > > > > >> On 09.11.15 15:45, Alexander Scherbatiy wrote: > >>> On 11/7/2015 11:38 AM, Jiri Vanek wrote: > >>>> Hello! > >>>> > >>>> Looking to imageIO.java (if this is bad thread, please redirect me!) > >>> > >>> 2d-dev alias should be also the right place to ask image related > >>> questions in AWT. > >>> > >>> Thanks, > >>> Alexandr. > >>> > >>>> when reading images > >>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 > >>>> > >>>> > >>>> > >>>> and ending at: > >>>> > >>>> // Perform mark/reset as a defensive measure > >>>> // even though plug-ins are supposed to take > >>>> // care of it. > >>>> boolean canDecode = false; > >>>> if (stream != null) { > >>>> stream.mark(); > >>>> } > >>>> canDecode = spi.canDecodeInput(input); > >>>> if (stream != null) { > >>>> stream.reset(); > >>>> } > >>>> return canDecode; > >>>> > >>>> I'm wondering, why stream.reset(); is not in finaly block: > >>>> > >>>> // Perform mark/reset as a defensive measure > >>>> // even though plug-ins are supposed to take > >>>> // care of it. > >>>> boolean canDecode = false; > >>>> if (stream != null) { > >>>> stream.mark(); > >>>> } > >>>> try{ > >>>> canDecode = spi.canDecodeInput(input); > >>>> } finally { > >>>> if (stream != null) { > >>>> stream.reset(); > >>>> } > >>>> } > >>>> return canDecode; > >>>> > >>>> > >>>> Eg png and bmp decoders can are throwing IIOException when header is > >>>> corrutped. That pretty definitely sure killer of stream mark stacks. > >>>> You yourselves write : //Perform mark/reset as a defensive measure > >>>> even though plug-ins are supposed to take care of it. > >>>> So if densive, then try/finaly please. > >>>> > >>>> I did not check if this changed in 9 but if not....Please. This is > >>>> makig work on custom image plugins, for image formats which just wraps > >>>> another bmp/png and are expecting corrupted headers preatty hards. > >>>> > >>>> > >>>> J. > >>> > >> > >> > > > > I've filed https://bugs.openjdk.java.net/browse/JDK-8144071 for this. The change looks good to me. I can confirm the reproducer fails on OpenJDK 6, 7 and 8: Exception in thread "main" java.lang.RuntimeException: exeption from call to canDecodeInput in ImageIO corrupted stack in ImageInputStream at MarkTryFinallyReproducer.main(MarkTryFinallyReproducer.java:317) I suggest the test case is converted to jtreg and the patch to OpenJDK 9 for a new webrev. Once that is posted, I can commit the change. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net) Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07 From james.graham at oracle.com Wed Nov 25 21:01:57 2015 From: james.graham at oracle.com (Jim Graham) Date: Wed, 25 Nov 2015 13:01:57 -0800 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: References: <564FBCED.4030501@oracle.com> <565385B1.2070308@oracle.com> Message-ID: <565621C5.2090201@oracle.com> Hi Laurent, Now that we've integrated the feature into the client repositories, all future work should be done in the client repository on a "one issue at a time, each fixed with a separate JBS issue" basis. At this point the GR repositories are now obsolete, though if we come up with another major feature that might need a sandbox we can keep them around for that future contingency, but the bulk of the work should now just be done in the regular client repository... ...jim On 11/25/15 2:35 AM, Laurent Bourg?s wrote: > Hi Jim, > > It seems that your changes made on the java2d patch (webrev.01) are not > present in the GR repository. > > See: > http://hg.openjdk.java.net/graphics-rasterizer/jdk9/jdk/ > > Could you merge (back) ? or later ... > > PS: I am synchronizing all my Marlin variants on my laptop (GR, github > branches ...) to be able to go forward. > > Thanks, > Laurent > > 2015-11-23 22:31 GMT+01:00 Jim Graham >: > > An updated webrev to fix the automated tests. The only changes are > to remove the package statements from the files in > test/sun/java2d/marlin/*.java: > > http://cr.openjdk.java.net/~flar/JDK-8076529/webrev.01/ > > The benchmark results were copied over from webrev.00 since there > are no expected changes in behavior or performance... > From bourges.laurent at gmail.com Fri Nov 27 09:54:42 2015 From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=) Date: Fri, 27 Nov 2015 10:54:42 +0100 Subject: [OpenJDK 2D-Dev] RFR: 8076529: Marlin antialiasing renderer integration In-Reply-To: <565363DA.40505@oracle.com> References: <564FBCED.4030501@oracle.com> <565363DA.40505@oracle.com> Message-ID: Hi, I fixed the CrashTest class to add jtreg tags and it passed with jtreg on my laptop. It needs 512mb for the heap but also 2Gb for off-heap arrays so the machine should have at least 3Gb of memory. Do you know how to define such requirements (@requires) ? Here is the webrev: http://cr.openjdk.java.net/~lbourges/marlin/marlin-s5.0/ Do you have already a bug id ? Laurent 2015-11-23 20:07 GMT+01:00 Sergey Bylokhov : > Hi, Jim. > It seems that the tests cannot be run via jtreg because of "package > marlin" in it. Also as far as I know there is a possibility in the latest > jtreg to filter out the system based on the ram, so is it possible to make > CrashTest.java automated? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexandr.scherbatiy at oracle.com Fri Nov 27 10:06:06 2015 From: alexandr.scherbatiy at oracle.com (Alexander Scherbatiy) Date: Fri, 27 Nov 2015 13:06:06 +0300 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <5654D6F0.3090702@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> <5654D6F0.3090702@oracle.com> Message-ID: <56582B0E.20405@oracle.com> Hello, Could you review the updated fix: http://cr.openjdk.java.net/~alexsch/8069348/webrev.02/ On 11/25/2015 12:30 AM, Jim Graham wrote: > Hi Alexandr, > > OSXOffScreenSD.java - what are these "rdar:" references? These are references to the internal Apple bug system. They have been contributed with the Mac OS X port: http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/ee9c8c9b5c2e > > OSXOffscreenSD.java - since this method just refers back to the SG2D, > how is it any better than just returning false and letting SG2D's > general copyArea deal with the issue? Also, SG2D.drawImage() is not > guaranteed to handle overlapping copyareas so arguably it could fail - > but I suppose the assertion is that the drawImage to such destinations > happens to deal with overlapping areas? Is that asserted or tested > anywhere? Also, this method claims that the Windows version ignores > the "light clip", but it doesn't. In fact, if there is a clip then > GDIcopyarea punts to the general version. I find a lot to worry about > in this implementation and I wonder how well it was tested...? I create a separate issue on it: JDK-8144181 OSXOffScreenSurfaceData.copyArea() method improvement > > (Note that other than the two issues I point out below with this file, > those concerns were not raised by this fix - it looks like a fairly > faithful translation of the questionable implementation to the new > scheme (ignoring the x/y bug below)) > > OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make > this part of the SD.copyArea contract, that the coordinates are in > device space and the SD method should not concern itself with the SG2D > transform? I updated the SurfaceData.copyArea() x,y,width, and height description. > > OSXOffscreenSD.java, line 511 - double check your x/y's Updated. > > OSXSD.java, line 1097 - typos: heavyweight, clipped Updated. > > X11SD.java & XRSD.java - (not an issue with this fix, but a question > for future work) needExposures? Do any of the other copyarea > implementations send repaint events? Shouldn't this be hard-coded to > false? More investigation is likely needed here. I moved it to the separate issue: JDK-8144179 GraphicsExposure event generation investigation in XCopyArea > > CopyAreaTest.java, line 52 - typo "BACKGROUND_COLOR" > > CopyAreaTest.java, line 61 - rounding is not the same operation that > SG2D uses, but it works anyway? > > CopyAreaTest.java, line 86 - perhaps move the scale to after you fill > the background? > > CopyAreaTest.java, line 94 - "Y + i * DX" => DY (that's odd, how did > the test pass?) > > CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah, > this may mask the error in line 94 above...? The test is updated according to the comments. Thanks, Alexandr. > > ...jim > > On 11/24/15 5:07 AM, Alexander Scherbatiy wrote: >> >> Hello, >> >> Could you review the updated fix: >> http://cr.openjdk.java.net/~alexsch/8069348/webrev.01/ >> >> - The given image sizes are transformed in the SG2D.doCopyArea method. >> The copyArea() methods are updated accordingly. >> - OGLSurfaceData.copyArea() method is updated to process scaled >> transforms. >> - The test which uses copyArea() method for VolatileImage is added. I >> left the test which moves internal frames for the Swing testing >> purposes. >> >> Thanks, >> Alexandr. >> >> >> On 11/20/2015 6:59 PM, Jim Graham wrote: >>> In terms of consolidating the code... >>> >>> Since SD.copyArea is an internal API, we could simply specify that it >>> takes pixel coordinates and assumes COPY semantics so it is up to SG2D >>> to verify the transform and compState and perform appropriate >>> coordinate transformations before asking the SD to do the dirty work. >>> I'm not sure why we left so much veto power up to the SD class there... >>> >>> ...jim >>> >>> On 11/20/15 7:38 AM, Sergey Bylokhov wrote: >>>> On 20.11.15 14:49, Alexander Scherbatiy wrote: >>>>> >>>>> Hello, >>>>> >>>>> Could you review the fix: >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8069348 >>>>> webrev: http://cr.openjdk.java.net/~alexsch/8069348/webrev.00 >>>>> >>>>> For some reasons Blit operation does not properly work in the >>>>> SunGraphics2D.copyArea() method >>>>> with scaled transform neither on Windows nor on Mac OS X. >>>>> I have filled an issue on it: JDK-8143392 SunGraphics2D.copyArea() >>>>> does not properly handle Blit operation >>>> >>>> Interesting. >>>> >>>>> >>>>> The current solution updates D3DSurfaceData.copyArea() to handle >>>>> scaled graphics in the same way >>>>> as it has been already done for the CGLSurfaceData (see >>>>> JDK-8000629 >>>>> [macosx] Blurry rendering with Java 7 on Retina display). >>>> >>>> Note that this fix does not help ogl on windows right? because on >>>> windows the usual ogl blit should be used since the fix for retina was >>>> osx specific. Or it works properly? >>>> >>>>> >>>>> May be there is a way to avoid the code duplication: put it to >>>>> some >>>>> SurfaceDataUtils class (it also >>>>> requires adding parent copyArea() method to BufferedRenderPipe) or >>>>> something else. I am not sure about the best option. >>>> >>>> This is up to the 2d team, but I think yes, it will be better to >>>> move it >>>> somewhere because after the current fix the different pipelines will >>>> behave differently on different platforms for a different >>>> transformations =( >>>> >>>>> >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>> >>>> >> From prasanta.sadhukhan at oracle.com Fri Nov 27 11:48:21 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Fri, 27 Nov 2015 17:18:21 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR JDK-7160052: GlyphVector.setGlyphPosition can throw an exception on valid input Message-ID: <56584305.70605@oracle.com> Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-7160052 webrev: http://cr.openjdk.java.net/~psadhukhan/7160052/webrev.00/ Issue: GlyphVector.setGlyphPosition(int glyphIndex, Point2D newPos) can have glyphIndex "equal" to the number of glyphs in this GlyphVector so if user tries to call GlyphVector.setGlyphPosition(gv.getNumGlyphs(), gv.getGlyphPosition(gv.getNumGlyphs()) it throws IndexOutOfBoundsException Cause: StandardGlyphVector maintains a glyph cache for the glyphs stored in the GlyphVector via lbcache = new Shape[glyphs.length]; When GlyphVector.setGlyphPosition() is called, it positions the glyph at the specified glyphIndex|||||||||| and tries to clear the mentioned glyphIndex position of cache by calling clearCache(glyphIndex) But, if we pass the glyphIndex == number of glyphs, then it tries to access beyond the cache array resulting in IOB. Fix: Checked if glyphIndex passed as argument is equal to number of glyphs then do not try to clear the cache as setGlyphPosition() will anyway sets the position after the last glyph. Also, added this check as per spec|IndexOutOfBoundsException | - if |glyphIndex| is less than 0 or greater than the number of glyphs in this |GlyphVector | Regards Prasanta |||| -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvanek at redhat.com Fri Nov 27 12:57:20 2015 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 27 Nov 2015 13:57:20 +0100 Subject: [OpenJDK 2D-Dev] [rfc]Stream doesn't reset mark in finally In-Reply-To: <1720362320.17383226.1448474028843.JavaMail.zimbra@redhat.com> References: <563DB869.80600@redhat.com> <5640957C.10702@oracle.com> <56449312.2000005@oracle.com> <564CB29C.10200@redhat.com> <56542B29.90202@redhat.com> <1720362320.17383226.1448474028843.JavaMail.zimbra@redhat.com> Message-ID: <56585330.7050500@redhat.com> On 11/25/2015 06:53 PM, Andrew Hughes wrote: > ----- Original Message ----- >> On 11/18/2015 06:17 PM, Jiri Vanek wrote: >>> On 11/12/2015 02:24 PM, Sergey Bylokhov wrote: >>>> Hi, Jiri. >>>> This is a valid point, did you file a new CR for this issue? >> >> ping? >> >>>> >>> >>> Hello! >>> >>> here it is: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/ >>> >>> Patch: >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/webrev/ >>> and reprodcuer >>> https://jvanek.fedorapeople.org/oracle/jdk8/webrevs/resetInTryFinally/v1/MarkTryFinallyReproducer.java >>> >>> >>> Reproducer can be easily turned to jtreg if wonted. >>> >>> The patch is for 8, but is valid also for 9, except the path to file. >>> I will adapt it to 9 once you are ok with it (or you may on your own, >>> depends on you) >>> >>> J. >>> >>> >>>> On 09.11.15 15:45, Alexander Scherbatiy wrote: >>>>> On 11/7/2015 11:38 AM, Jiri Vanek wrote: >>>>>> Hello! >>>>>> >>>>>> Looking to imageIO.java (if this is bad thread, please redirect me!) >>>>> >>>>> 2d-dev alias should be also the right place to ask image related >>>>> questions in AWT. >>>>> >>>>> Thanks, >>>>> Alexandr. >>>>> >>>>>> when reading images >>>>>> http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/javax/imageio/ImageIO.java#l543 >>>>>> >>>>>> >>>>>> >>>>>> and ending at: >>>>>> >>>>>> // Perform mark/reset as a defensive measure >>>>>> // even though plug-ins are supposed to take >>>>>> // care of it. >>>>>> boolean canDecode = false; >>>>>> if (stream != null) { >>>>>> stream.mark(); >>>>>> } >>>>>> canDecode = spi.canDecodeInput(input); >>>>>> if (stream != null) { >>>>>> stream.reset(); >>>>>> } >>>>>> return canDecode; >>>>>> >>>>>> I'm wondering, why stream.reset(); is not in finaly block: >>>>>> >>>>>> // Perform mark/reset as a defensive measure >>>>>> // even though plug-ins are supposed to take >>>>>> // care of it. >>>>>> boolean canDecode = false; >>>>>> if (stream != null) { >>>>>> stream.mark(); >>>>>> } >>>>>> try{ >>>>>> canDecode = spi.canDecodeInput(input); >>>>>> } finally { >>>>>> if (stream != null) { >>>>>> stream.reset(); >>>>>> } >>>>>> } >>>>>> return canDecode; >>>>>> >>>>>> >>>>>> Eg png and bmp decoders can are throwing IIOException when header is >>>>>> corrutped. That pretty definitely sure killer of stream mark stacks. >>>>>> You yourselves write : //Perform mark/reset as a defensive measure >>>>>> even though plug-ins are supposed to take care of it. >>>>>> So if densive, then try/finaly please. >>>>>> >>>>>> I did not check if this changed in 9 but if not....Please. This is >>>>>> makig work on custom image plugins, for image formats which just wraps >>>>>> another bmp/png and are expecting corrupted headers preatty hards. >>>>>> >>>>>> >>>>>> J. >>>>> >>>> >>>> >>> >> >> > > I've filed https://bugs.openjdk.java.net/browse/JDK-8144071 for this. Here you go! https://jvanek.fedorapeople.org/oracle/jdk9/webrevs/resetInTryFinally/v2/ > > The change looks good to me. I can confirm the reproducer fails > on OpenJDK 6, 7 and 8: > > Exception in thread "main" java.lang.RuntimeException: exeption from call to canDecodeInput in ImageIO corrupted stack in ImageInputStream > at MarkTryFinallyReproducer.main(MarkTryFinallyReproducer.java:317) > > I suggest the test case is converted to jtreg and the patch to done > OpenJDK 9 for a new webrev. Once that is posted, I can commit done > the change. > TYVM! I run all jtregs, and looked ok. J. From james.graham at oracle.com Fri Nov 27 22:43:28 2015 From: james.graham at oracle.com (Jim Graham) Date: Fri, 27 Nov 2015 14:43:28 -0800 Subject: [OpenJDK 2D-Dev] Review request for 8069348 SunGraphics2D.copyArea() does not properly work for scaled graphics in D3D In-Reply-To: <56582B0E.20405@oracle.com> References: <564F08B6.7010009@oracle.com> <564F3E8C.3040400@oracle.com> <564F4360.3070609@oracle.com> <5654610C.2090302@oracle.com> <5654D6F0.3090702@oracle.com> <56582B0E.20405@oracle.com> Message-ID: <5658DC90.2010801@oracle.com> Hi Alexandr, On 11/27/15 2:06 AM, Alexander Scherbatiy wrote: >> OSXOffscreenSD.java (and all *SD.java), line 481 - should we just make >> this part of the SD.copyArea contract, that the coordinates are in >> device space and the SD method should not concern itself with the SG2D >> transform? > I updated the SurfaceData.copyArea() x,y,width, and height > description. And yet most of the implementations still check the transformState. Why do they do that if they are no longer concerned with transforming the inputs? >> CopyAreaTest.java, line 61 - rounding is not the same operation that >> SG2D uses, but it works anyway? The rounding still isn't the same as SG2D. Floor() != ceil(v - 0.5). On second thought, it's probably best not to worry about the exact rounding in the test case, but just test 1 pixel inset from the coordinates that are needed. In other words, check: scale(X + (N+1) * DX) + 1 scale(Y + (N+1) * DY) + 1, scale(W) - 2 scale(H) - 2 and go back to just rounding... >> CopyAreaTest.java, lines 143,144 - why subtract 2DX and 2DY here? Ah, >> this may mask the error in line 94 above...? I notice that it used to check the rectangle at X+(N+1)*DX, Y+(N+1)*DY, but now it only checks X+N*DX,Y+N*DY. Why not continue to check the N+1 copy? That should be the location of the destination of the last copy, right? ...jim From prasanta.sadhukhan at oracle.com Mon Nov 30 08:43:09 2015 From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan) Date: Mon, 30 Nov 2015 14:13:09 +0530 Subject: [OpenJDK 2D-Dev] [9] RFR: JDK-8140530, , Creating a VolatileImage with size 0, 0 results in no longer working g2d.drawStri Message-ID: <565C0C1D.3080408@oracle.com> Hi All, Please review a fix for jdk9 Bug: https://bugs.openjdk.java.net/browse/JDK-8140530 webrev: http://cr.openjdk.java.net/~psadhukhan/8140530/webrev.00/ The issue was creating a volatileImage with 0 width, height does not result in IllegalArgumentException. But, when we try to create a non-volatile Image via GraphicsConfiguration.createCompatibleImage(0,0) or a BufferedImage(0,0,imagetype) it results in IAE. So, to maintain consistency across all image w.r.t 0 width,height, createVolatileImage() should also throw IAE. In windows, creating a volatileImage with 0 width,height resulted in IAE but in linux it does not. This is because XCreatePixmap() generate BadValue unless width,height is nonzero but the error handler does not catch it. https://tronche.com/gui/x/xlib/pixmap-and-cursor/XCreatePixmap.html [The width and height arguments must be nonzero, or a *BadValue* error results.] I have added a check to prevent zero width,height to be used for XCreatePixmap() and also throw OOME so to ask Java to throw IAE. Regards Prasanta -------------- next part -------------- An HTML attachment was scrubbed... URL: